[prev in list] [next in list] [prev in thread] [next in thread] 

List:       shibboleth-dev
Subject:    Re: [Shib-Dev] [IdPv3] Attribute Resolver Work
From:       Chad La Joie <lajoie () itumi ! biz>
Date:       2010-06-02 18:45:37
Message-ID: 4C06A6D1.7040701 () itumi ! biz
[Download RAW message or body]

One thing I haven't discussed yet is the new profile/message context 
APIs.  Currently the plans for these aren't in a form anyone other than 
probably Brent or I to consume.  We're working on getting that fixed.  I 
can say that the new APIs will allow any information stuffed in to the 
context to be carried forward from the authentication engine in to the 
attribute resolver (and beyond).

Now, this doesn't magically do what you want.  For such information 
people will still end up having to write a login handler that knows what 
information is important and puts it in to the context.  But there will 
at least be a clean way to carry all of that data threw the entire process.

On 5/26/10 4:21 PM, Paul Hethmon wrote:
> Sure.
>
> A situation I'm exploring today is supporting a non-unique login ID
> namespace with a single IdP. Login IDs are essentially made unique based on
> the relying party the user wants to access:
>
>   joe + rp1 != joe + rp2
>
> So, at the IdP auth layer, I can gather this information based on the
> relying party info.
>
> What I would like to do is be able to convey that information in an
> attribute because sometimes I may not send the user back to the requested
> relying party. Instead, this user may be required to execute a change
> password which goes to another relying party site altogether. That third
> party site needs to know what is the user's original relying party
> information.
>
> In essence, I'm multi-plexing distinct systems into a single system to save
> the overhead of creating multiple systems.
>
> Another use I can think of is my one relying party that wants me to muck
> with their relay state information. If I can create attribute data at the
> servlet level, then I can convey that information to them in a proper
> attribute instead of having to munge what should be opaque data.
>
> Overall, I seem to have a lot of information available at authentication
> that could be useful, but is not easily available outside of the
> authentication context.
>
> I haven't looked at the data connector code, but from what I have looked at
> inside of Shib, it seems that you could create a data connector that can
> pull information out of the session store. So, inside of the authentication
> servlet, it uses a method out of HttpHelper to store name/value or perhaps
> name/object pairs? The new data connector would simply access that data
> store when called.
>
> Paul
>
>
>
> On 5/26/10 4:00 PM, "Chad La Joie "<lajoie@itumi.biz>  wrote:
>
>> Can you explain a bit more about what you mean?  I'm not sure I understand.
>>
>> On 5/26/10 2:24 PM, Paul Hethmon wrote:
>>> Chad,
>>>
>>> One new thing I would like to see is a way for the authentication servlet to
>>> set information for attributes. So basically a data connector to the
>>> authentication servlet.
>>>
>>> thanks,
>>>
>>> Paul
>>>
>>>
>>>
>
>

-- 
Chad La Joie
http://itumi.biz
trusted identities, delivered
[prev in list] [next in list] [prev in thread] [next in thread]