Skip to Content.
Sympa Menu

shibboleth-dev - Re: Re: SV: IdP Extension

Subject: Shibboleth Developers

List archive

Re: Re: SV: IdP Extension


Chronological Thread 
  • From: "Tom Scavo" <>
  • To:
  • Subject: Re: Re: SV: IdP Extension
  • Date: Wed, 25 Oct 2006 08:46:17 -0400
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pbfHy5iqJ16SrgNGEDO+JFeT9G/Fj1P+nCtFF7Jv8rKi8qJpT2cFBTwQ9xOuQNcchDgqLVQr9iLPS2Dkycp97j+mhd4sFOqSUUkX4yhVQOtrteyVCVXTV5oLPpAzRChW1HYU8aclEU3ono1+ii4++ewwKFa1ih81G3GywlhgKL4=
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