Les Hazlewood schrieb: > 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.
yeah i tried it and didn˚t like the working result :o so i rethought and came to a solution like this: right now i just manipulate the principalcollection of the current subject and let my special url realm add the special urls as SpecialPrincipals to it. And on authentication my realm gets all relevant principals from the current subject and puts ˚em in the AuthenticationInfo, so they will get aggregated too To find out if the user is authenticated (really logged in) i use a Role and check for that. looking at the code this looks nicer to me :) regards and thx for your feedback Christian
signature.asc
Description: OpenPGP digital signature
