Les Hazlewood wrote:
> A Shiro Subject is just a security-specific 'view' of a single
> application user. The subject can have many principals, and
> internally Shiro remembers from which realms all of the principals
> came from. This makes it easy for Realm implementors to acquire only
> the principals their realm 'cares about' and ignore other principals
> that perhaps came from other Realm implementations that may be in use
> as well (e.g. multi-realm PAM scenarios)
I'm confused, I thought a realm in Shiro was simply a mechanism to retrieve
security information from some datasource?
You're correct - a Realm is essentially a security-specific DAO.
Typically, you have a single Realm per datasource.
What you suggest here seems to be saying that I should also consider a realm
as a way to implement the 'virtual hosts' idea that comes along with Oauth
(each consumer is effectively seen as though it were accessing a virtual
host on the the app server, and each has their own view of the users
including login credentials, roles and permissions).
I brought up the multi-realm scenario to illustrate why principals are
grouped by realm. Most of the time, multiple realms are configured
for applications that have their security data spread across multiple
data sources.
ok, then I dont think this is the right choice to use as its not a PAM
scenario.
For example, it is common in many applications to authenticate against
LDAP but retrieve the application's authorization data (roles/perms)
from an RDBMS.
agreed, but typically roles and permissions do not alter per user, so
LDAP for SSO + local app permissions makes sense.
But with Oauth there is no SSO, its the complete opposite where all user
authorised applications have different credentials and permissions to
access the same application (as the same user, they just dont know it)
However, if the default configuration does not suit your needs, you
could always implement your own Authenticator implementation though
that does whatever you want and plug that in to the SecurityManager.
For example, perhaps based on a submitted AuthenticationToken, you
know exactly which realm to consult - then your Authenticator
implementation could acquire the realm directly from a map and use
only that realm and ignore all others. Then it would be perfectly
fine to have a large number of realms since the realm lookup would be
a constant time operation.
This may be a good approach for the 'virtual hosts' perspective that
you explain above. Is there a way to know which realm to consult
based on the submitted authentication token? Say, username, password,
and some other attribute that knows to 'point' to a particular realm?
- Les
there is! the data that gets sent as part of the signature includes the
consumer key, so its possible to structure like this:
for 2 consumers + 4 actual application accounts (appusers):
consumerkey1->usertokenkey1->permissionsetA->appuser1
->usertokenkey2->permissionsetB->appuser2
->usertokenkey3->permissionsetC->appuser3
->usertokenkey4->permissionsetD->appuser4
consumerkey2->usertokenkey5->permissionsetE->appuser1
->usertokenkey6->permissionsetF->appuser2
->usertokenkey7->permissionsetG->appuser3
->usertokenkey8->permissionsetH->appuser4
...
Caching keyed on consumerkey+usertoken is ok, but if an appuser is
removed then all references need to be discoverable and removed too so a
cache that understands groups would be helpful.
I'd like to store this in an ldap directory but not sure how.
