Les, I hadn't considered a custom AuthenticationToken but obviously that's a better approach than storing an object in the Session. I like solution #2 below, thanks!
Ryan On Mon, Jun 6, 2011 at 4:21 PM, Les Hazlewood <[email protected]> wrote: > Hi Ryan, > > There are 2 ways that I can think of solving this off of the top of my > head: > > 1. Your Realm implementations override the 'supports' method and only > return true based on the AuthenticationToken passed in. You can > create a custom AuthenticationToken that stores whatever additional > information you need (e.g. host + port) and the realm can choose to > process it based on matching. > > This would work because the SecurityManager's internal Authenticator > always checks the 'supports' method before interacting with a Realm. > All realms that 'support' a token will be consulted, and the internal > AuthenticationStrategy determines what happens as each realm is > consulted. You could also plug in a custom AuthenticationStrategy > depending on your needs and if the 'supports' approach is good enough > or not. > > 2. You create a custom Authenticator and plug it in to the > SecurityManager. The Authenticator can look at the custom > AuthenticationToken and based on that token, dispatch it to one or > more appropriate realms. > > I like the 2nd approach more since the Realms don't need to check for > specific tokens other than their basic format (username/password or > biometric, etc). They can stay more general-purpose. Keeping the > routing logic out of the Realms feels cleaner to me. > > Does that help? > > Cheers, > > -- > Les Hazlewood > CTO, Katasoft | http://www.katasoft.com | 888.391.5282 > twitter: http://twitter.com/lhazlewood > katasoft blog: http://www.katasoft.com/blogs/lhazlewood > personal blog: http://leshazlewood.com >
