Shibboleth Developers

[Walter Hoehn <>]

Attribute push.

-Walter


On Oct 25, 2006, at 8:06 AM, André Cruz wrote:

> I didn't quite get that. I think we are talking about different  
> things.
>
> An example:  I want to generate an attribute based on the IP  
> address of
> the user. Since
> the data connectors don't receive this kind of information it was
> suggested that we store it
> before in a ThreadLocal variable and fetch it during attribute  
> generation.
>
> The way to store it would be in a servlet filter that intercepted the
> browser request to the SSO handler.
> But the attribute generation is done when an SP does an AA request to
> the IdP (maybe I'm wrong here?),
> therefore, in a different request. For this to work these two requests
> would have to be served by the same
> thread and sequentially.
>
> There must be something wrong with my theory but I haven't figured it
> out yet. :)
>
> André
>
> Tom Scavo wrote:
> > On 10/25/06, 
> >
> >  
> > <>
> >  wrote:
> > > But how can we be sure that the same thread that processes the HS
> > > request from the browser will be the same that processes the AA
> > > request from the SP to the IdP?
> >
> > I think you're using the term "thread" a little differently.  To
> > answer your question directly, it is up to the IdP to map the
> > NameIdentifier in the attribute query to one and only on principal in
> > its security domain.  How it does this depends on the NameIdentifier.
> > If the NameIdentifier is an opaque ShibHandle issued as a result of
> > browser SSO, either the corresponding principal name is retained at
> > the IdP for later use (SharedMemoryShibHandle) or the principal name
> > is encrypted right into the handle itself (CryptoShibHandle).  For
> > other NameIdentifiers, it just "depends".
> >
> > Tom