Skip to Content.
Sympa Menu

shibboleth-dev - Re: SV: IdP Extension

Subject: Shibboleth Developers

List archive

Re: SV: IdP Extension


Chronological Thread 
  • From: André Cruz <>
  • To:
  • Subject: Re: SV: IdP Extension
  • Date: Wed, 25 Oct 2006 14:06:53 +0100

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




Archive powered by MHonArc 2.6.16.

Top of Page