Hi Christian, Typically you don't need to create subclasses of the SecurityManager - you can set up multiple Realms, and each realm can choose to participate in the login or not by inspecting the AuthenticationToken. The principals from all realms are combined after log-in as an aggregate to represent the Subject's identity - they typically don't 'overwrite' each other.
If you need very fine-grained control over how Realms are consulted and the aggregate AuthenticationInfo is constructed, you could always inject your own AuthenticationStrategy into the SecurityManager. Your implementation would create the aggregate AuthenticationInfo object however you desire. Check out all the existing AuthenticationStrategy implementations first before you spend too much time on that though - there may be something that you already need. Specifically, the 'AtLeastOneSuccessful' strategy might be what you want. Best regards, Les On Sun, Jun 14, 2009 at 7:39 AM, Christian Schröder <[email protected]> wrote: > Hello, > i was wondering what is a common way to add permissions and principals > to the current subject. > > in our web application there are semi-private urls (a long non guessable > hash) which are used to grant anonymous users access to this resource. > > solutions i can think of: > 1 special Token and realm and then using subject.login() > + easy to do > + logins can happen at different times and in different order > - multiple logins overwrite each other with the DefaultsecurityManager > 2 having a list of "collected" keys in a principal > + seems reasonable > - need to invalidate authorizationcaches > - principals would have to be merged manually on every login > > Solution 1 seems to need a new securitymanager which overwrites > > protected Subject createSubject(AuthenticationToken token, > AuthenticationInfo info) > > to have the possibilty to have multiple logins which add information to > the current subject and not create a new subject. That way i could go > with multiple realms and multiple logins to achieve my goal. this seems > also a best fit to the problem domain. > > On a side not this would make remember me easier too, (being just a > special realm and not spread in the securitymanager). > > Is this a reasonable approach? Or is there some kind of best practice > already? > > some cases to make this clearer (hopefully): > anonymous -> special url for object -> ACCESS to object > loggedin -> NO ACCESS to object > loggedin as author of object -> ACCESS to object > loggedin -> special url for object -> ACCESS to object > anonymous -> special url for object -> login -> ACCESS to object > > the last case requires this new Default Security Manager > > > regards > Christian > > > > -----BEGIN PGP SIGNATURE----- > > iD8DBQFKNN3bd1zGxPhGhFcRA71vAKDQPhZlJ+bJtb4hQTQg/J1e7uazbgCeKBQK > kNClnmjSvqnL7Ho6XZs/ubw= > =/lux > -----END PGP SIGNATURE----- > > >
