>> > 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. For example, it is common in many applications to authenticate against LDAP but retrieve the application's authorization data (roles/perms) from an RDBMS. > With Shiro, is it ok to configure multiple Realms (thousands of them) with > the same implementation, pointing to the same datasource? It is not recommended to do this with Shiro's default configuration. The default ModularRealmAuthenticator, the component that performs PAM authentication when more than one Realm is configured, iterates over the collections of Realms one by one, passing each one to an AuthenticationStrategy which determines exactly how the authentication attempt(s) should occur. If you have a very large number of Realms, the iteration could take a long time. 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
