[Concordia] A wiki page for our IdP Discovery Problem educational materials
Paul Madsen
paulmadsen at rogers.com
Tue Jan 22 11:25:58 EST 2008
Hi Mikael, LAP explored these sorts of inter-COT issues in
http://www.project*liberty*.org/.../23105/file/access-to-identity-enabled-services-in-inter-cot-scenarios-v1.0.pdf
I think your scenario is covered in the chapter 'Inter-Federation
(Inter-CoT) Discovery'.
FYI, ID-WSF has its Identity Mapping Service (IMS), enabling comparable
functionality to WS-Trust token exchange.
paul
Mikaël Ates wrote:
> Josh, you are totally right, it would have been better if I have kept
> the distinction between the discovery and trust path establishment
> issues.
> I think that the first one can be resolved in a manner listed by Eve.
> An information (for me, a "hint") given to the SP (whatever passive or
> active client process used) combined with the SAML2 Metadata
> Publication and Resolution part seem to be enough.
> The second question is now about trust path establishment i.e. I have
> discovered the IdP but for the moment I do not trust it yet, i.e. I
> have its signature but I do not trust his signature yet.
> What I said only rely on indirect trust, i.e. I can establish trust
> paths thanks to the public metadata. Thanks to the discovery process I
> can match one of these trust paths. I have now two possibilities, my
> requests/responses pass through every node with resignatures like
> SAML2 IdP proxying (heavy process but allows my SP and IP to manage
> few signatures, the discovery process has only been used to match the
> right trust path and the IdP signature + endpoints are useless for the
> SP) or the SP adds the IdP metadata to its whitelist of trusted IdP
> (the discovery process has been used to match the right trust path and
> to obtain the metadatas).
>
> Paul, if I still authorize indirect (transitive) trust, could the
> issue be the same with ID-WSF? I mean, the WSC and the WSP could trust
> a different DS and these DS could be trust linked. So the WSC could
> obtain a token from its DS, exchange it to the WSP'DS, and present
> this new token to the WSP (In a WS-Trust manner in fact...).
>
> Regards,
> Mikaël
>
> Paul Madsen wrote:
>> FYI, Liberty's Discovery Service typically does link discovery and
>> trust.
>>
>> When an Identity Requestor queries a user's Discovery Service (DS)
>> for the location of some attribute (e.g. geolocation), the DS returns
>> both
>>
>> - the endpoint of the user's geolcoation service
>> - a security token (a SAML assertion) for the identity requestor to
>> use at the above endpoint (thereby allowing the DS to broker trust
>> between the requestor and the endpoint)
>>
>> this is seen as an optimization of having the requestor perform two
>> separate calls, one to discover, and another to get a security token
>>
>> I do acknowledge that this type of service discovery is different
>> than the more fundamental 'IDP discovery' problem.
>>
>> regards
>>
>> paul
>>
>> Mikaël Ates wrote:
>>> Hi Josh,
>>>
>>>> Discovery and trust path establishment are orthogonal. As an
>>>> analogy, you can use TLS to estalish trust with a peer whose
>>>> network address you have discovered using insecure DNS.
>>>>
>>> In fact, in the process I described, the both are linked... The
>>> discovery of the authority is the same as the discovery of the trust
>>> path, and so, how to establish an indirect trust link. As an
>>> analogy, TLS gives you signatures but does not say how you can trust
>>> a signature. In a federation, maybe you have a common PKI, a white
>>> list of trusted signatures, and if you rely on indirect trust, you
>>> can trust the trusted parties of your trusted parties.
>>>
>>>> IIRC, eduGAIN (like the Shibboleth profile) does not consider
>>>> discovery to be in-scope.
>>>>
>>> I do not know technical details of eduGAIN but I found this in the
>>> eduGAIN deliverable DJ5.2.2:
>>> "Home Location Service, in charge of *locating the appropriate
>>> identity repository at the home domain*"
>>> "An eduGAIN Home Location Request is a message sent via the
>>> federation peering point to determine the home
>>> interfaces where an authentication or attribute request can be
>>> satisfied, and to *establish trust among these
>>> interfaces and the requesting element*.
>>>
>>> Regards,
>>> Mikaël
>>>
>>>
>>>> best regards, josh.
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: community-bounces at projectconcordia.org
>>>>> [mailto:community-bounces at projectconcordia.org] On Behalf Of
>>>>> Mikaël Ates
>>>>> Sent: 22 January 2008 10:03
>>>>> To: Eve Maler
>>>>> Cc: community at projectconcordia.org
>>>>> Subject: Re: [Concordia] A wiki page for our IdP Discovery Problem
>>>>> educational materials
>>>>>
>>>>> Hi the Concordia community,
>>>>>
>>>>> Eve have posted about the "where are you from" issue. I am also
>>>>> working on this (like everyone I guess...) so I would be pleased
>>>>> if anybody could give me his opinion about something like "Say me
>>>>> something about you, I will say you where you are from" and also
>>>>> if you ever hear something about this? In fact, these works mainly
>>>>> concern trust path establishment.
>>>>>
>>>>> I suppose that the SP/RP and the Authority (STS, SAML IdP,
>>>>> etc...) are not directly trust linked. So there is "n" indirect
>>>>> trust links and n+1 nodes. The nodes at the boundaries are the
>>>>> security information (token, assertion,
>>>>> etc...) producer and consumer. The "middle nodes" ensure what
>>>>> SAML2 called "IdP proxing", which means for me transitive trust. I
>>>>> called them trusted nodes. The issue is: the user is "on" the SP
>>>>> and want to authn (or else) on an Authority indirectly trusted by
>>>>> the SP (Does it sound like a reallife case?).
>>>>> I suppose that the Authority and trusted nodes metadatas are
>>>>> "publicly"
>>>>> avaible which means that all the trust links can be known. So it
>>>>> also means that it is feasable for an SP or a dedicated entity
>>>>> (maybe a "trust router") to construct a complete "trust path table".
>>>>> The SP asks the user a "hint", something like a URI or a domain
>>>>> name. The SP presents the user a form or a claim requirement
>>>>> (satisfied by an infocard containing the hint). With this hint the
>>>>> SP is able to match one of the trust paths.
>>>>> So the SP redirects the user to the first trusted node of the
>>>>> path, which the SP directly trusts. The SP also gives the hint
>>>>> while the redirection. Hence, the trusted node will perform an
>>>>> other "jump" in the
>>>>> path: matching and redirection.
>>>>> One of the application I see is for a sort of internationnal
>>>>> confederation. For now, you would have choosen your country on the
>>>>> SP for the first redirection, your organization on the trusted
>>>>> node, and then you would have authenticated on your IdP. There, we
>>>>> only have one trusted node, so it is feasable to require the human
>>>>> intervention to establish the trust path. But it is not if we have
>>>>> n trusted nodes...
>>>>> In fact, some confederation project (eduGAIN) rely on a common
>>>>> PKI, so there is a common "metadatas pool" of the confederation
>>>>> which allows to search (also thanks to a hint) the IdP directly in
>>>>> the metadatas, and dynamically establish a direct trust link
>>>>> between the SP and the IdP.
>>>>> Here, I treat another case, in which we don't have a common PKI or
>>>>> whatever secondary common trust architecture which would allow a
>>>>> dynamic direct trust establishment. In the case of a dynamic
>>>>> direct trust establishment, the SAML ECP profile or Infocard tech
>>>>> would be enough to solve the WAYF issue. In fact, there is common
>>>>> trust architecture which would be the (con)federation by itself.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Mikaël Ates
>>>>> DIOM Laboratory - ISTASE School of Engineering University of
>>>>> Saint-Etienne - FRANCE mikael.ates at univ-st-etienne.fr
>>>>> +33 4 77 43 50 34
>>>>>
>>>>> Eve Maler wrote:
>>>>>
>>>>>> I finally created a place to put our IdP discovery thoughts; that
>>>>>> action has been hanging out there for a while. Please feel free
>>>>>> to edit, correct, flesh out, etc. Scott and Jeff and George, I'd
>>>>>> be especially grateful for your contributions since we all
>>>>>> indicated interest in carrying this forward.
>>>>>>
>>>>>>
>>>>>>
>>>>> http://projectconcordia.org/index.php/The_Identity_Provider_Discovery_
>>>>>
>>>>>
>>>>>> Problem
>>>>>>
>>>>>> By the way, in some private conversations I've been having,
>>>>>>
>>>>> it seems
>>>>>
>>>>>> deployers would find a similar exercise for single logout to be
>>>>>> useful. It's got some of the same characteristics: sensitive to
>>>>>> UI concerns, decisions get based as much on business as technical
>>>>>> considerations, confusing, no one perfect solution vs. lots of
>>>>>> imperfect solutions that involve tradeoffs... If you're
>>>>>>
>>>>> interested,
>>>>>
>>>>>> please raise your hand (or just start writing a new page!).
>>>>>>
>>>>>> Eve
>>>>>>
>>>>>> Eve Maler +1 425 947 4522
>>>>>> Principal Engineer eve.maler @ sun.com
>>>>>> CTO Business Alliances group Sun Microsystems, Inc.
>>>>>>
>>>>>> _______________________________________________
>>>>>> Community mailing list
>>>>>> Community at projectconcordia.org
>>>>>> http://lists.projectconcordia.org/mailman/listinfo/community
>>>>>>
>>>>>> Participating in this discussion list does not grant any
>>>>>>
>>>>> intellectual property rights or any commitment by the participants
>>>>> of the content discussed to any organization.
>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Community mailing list
>>>>> Community at projectconcordia.org
>>>>> http://lists.projectconcordia.org/mailman/listinfo/community
>>>>>
>>>>> Participating in this discussion list does not grant any
>>>>> intellectual property rights or any commitment by the participants
>>>>> of the content discussed to any organization.
>>>>>
>>>>>
>>>> JANET(UK) is a trading name of The JNT Association, a company limited
>>>> by guarantee which is registered in England under No. 2881024 and
>>>> whose Registered Office is at Lumen House, Library Avenue,
>>>> Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG
>>>>
>>>> _______________________________________________
>>>> Community mailing list
>>>> Community at projectconcordia.org
>>>> http://lists.projectconcordia.org/mailman/listinfo/community
>>>>
>>>> Participating in this discussion list does not grant any
>>>> intellectual property rights or any commitment by the participants
>>>> of the content discussed to any organization.
>>>>
>>>
>>> _______________________________________________
>>> Community mailing list
>>> Community at projectconcordia.org
>>> http://lists.projectconcordia.org/mailman/listinfo/community
>>>
>>> Participating in this discussion list does not grant any
>>> intellectual property rights or any commitment by the participants
>>> of the content discussed to any organization.
>>>
>>>
>>>
>>
>
>
>
--
Paul Madsen e:paulmadsen @ ntt-at.com
NTT p:613-482-0432
m:613-282-8647
aim:PaulMdsn5
web:connectid.blogspot.com
More information about the Community
mailing list