Shibboleth Developers

[André Cruz <>]

Thank you. I hadn't gotten to the part about Alternative Profiles yet.

I read about it, switched to Artifact/Attribute Push and now it works.
André

Walter Hoehn wrote:
> 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
>>
>