attribute resolution during the login process

[Cantor, Scott]

On 8/1/13 9:44 AM, "Paul Hethmon" <paul.hethmon at clareitysecurity.com>
wrote:

>I have a need to resolve some attributes after the user has been
>authenticated but prior to releasing control back to the profile handler
>in the Multi-Context Broker. I have to get a list of allowed
>authentication contexts for a user to see what they are allowed to use.
>So instead of defining yet another attribute mechanism, I would like to
>pull in the attribute resolver and have it do the job for me. After
>walking through code and configuration files for the last day, I'd like
>to see if this seems reasonable:

If you look at my login handler extension from OSU, it includes some
generic code for this. I have it in production. It's based on code Jim Fox
did, and his code actually was directed at this exact use case.

I generalized it a bit to be able to invoke the resolver with a specific
list of requested attributes to resolve, which is a bit more efficient
than the usual resolver practice of resolving everything.

>1. Get a handle to the attribute resolver service from the servlet context
>2. Create necessary data structures the attribute resolver needs
>3. Let it resolve the attributes for the principal
>4. Pull out what I need
>5. Complete the authentication process
>
>So is getting that handle to the base service and using it the right way
>to go?

I believe that's how I did it, but you can look and see.

The primary issue is that some scripts may depend on some of the request
context, such as the requester's ID. It's important to consider what to
populate the context with, but as long as it's documented/consistent,
anything can work.

-- Scott