Here is some more background information on this topic.
1. Our first attempt at this was done in the Open Grid Forum Authz
working group several years ago and the result is documented in a couple
of draft OGF profiles. In this case, the PEP knows the user's
distinguished name from his X.509 PKC, and this is passed to the context
handler/PDP as a subject attribute in the request context. It is assumed
that the user's attributes are assigned to this DN at all the different
attribute authorities. In order to request that the PIP pull attributes
from a given set of AAs/IDPs, the PEP places an IDPLIst element into the
request context as an environmental attribute with
ID= http://schemas.ogf.org/ogsa-authz/2008/09/attribute/IDPList.
IDPList is defined below
<element name="IDPList" type="samlp:IDPListType"/>
<complexType name="IDPListType">
<sequence>
<element ref="samlp:IDPEntry" maxOccurs="unbounded"/>
<element ref="samlp:GetComplete" minOccurs="0"/>
</sequence>
</complexType>
<element name="GetComplete" type="anyURI"/>
<element name="IDPEntry" type="samlp:IDPEntryType"/>
<complexType name="IDPEntryType">
<attribute name="ProviderID" type="anyURI" use="required"/>
<attribute name="Name" type="string" use="optional"/>
<attribute name="Loc" type="anyURI" use="optional"/>
</complexType>
2. Our second attempt was performed more recently in the EC TAS3
project. In this case we wish to protect the user's privacy so there is
no globally unique DN that is known by all the IDPs/AAs. Instead we have
a web service, called a linking service, which is a special type of PIP
controlled by the user, and this knows the mapping of the user's various
IDs between his IDPs (only the ones the user wishes to release, I might
add). The user also sets up a policy at the PIP telling it which IDPs to
contact for which attributes for which SPs. In this case the PIP has to
pull the user's attributes from the various IDPs and return them to the
context handler. Because there can be many of these linking services,
their location cannot be hard coded into the application. Instead the
PEP dynamically sends details about the PIP to the context handler in
the request context message. Our first attempt to do this was to define
a special attribute (an ID-WSF EPR) which was inserted into the
subject's attributes.
3. The third attempt was to do this, places the ID-WSF EPR into the SOAP
header, wrapped in WSSE security token. More details of this are given
by Sampo in his message below.
Conclusion. There has been a requirement to pull credentials for many
years, and different solutions have been proposed. Can the XACML group
standardise a preferred solution.
I take it that the conference call today is 18.00 UK time (19.00
European time)
regards
David
On 20/10/2010 23:25, wrote:
> David Chadwick<> said:
>
>> Hi everyone
>
>>
>
>> in the TAS3 project we have been developing the PDP to be able to pull
>
>> various user credentials from different IDPs. We use the SAML/XACML
>
>> protocol to communicate between the PEP and the PDP. One of the things
>
>> we need to do is for the PEP to direct the PIP of the PDP where to go to
>
>> fetch extra user attributes/credentials/claims. The solution we are
>
>> proposing is to put a WSSE security token in the SOAP header of the SAML
>
>> request.
>
>
>
> To be more specific, we make call like SOAP(WSSE(A7N1(DIBS(A7N2))),XACML-SAML(...))
>
> where
>
>
>
> A7N1 identifies the user at PEP and DIBS is the user's ID-WSF discovery bootstrap (A7N2 is user's
>
> identification at the discovery service). The DIBS component allows the PDP/PIP to make
>
> calls to user's attribute or credential authorities to pull any credentials that were not
>
> pushed.
>
>
>
> Cheers,
>
> --Sampo
>
>
>
>> What do the group think about this approach?
>
>>
>
>> Have other ways of directing the PIP been discussed?
>
>>
>
>> Is the group willing to standardise the way that the PEP can dynamically
>
>> inform the PDP/PIP where to pull additional attributes/claims from
>
>>
>
>> regards
>
>>
>
>> David
>
>>
>
>> --
>
>>
>
>> *****************************************************************
>
>> David W. Chadwick, BSc PhD
>
>> Professor of Information Systems Security
>
>> School of Computing, University of Kent, Canterbury, CT2 7NF
>
>> Skype Name: davidwchadwick
>
>> Tel: +44 1227 82 3221
>
>> Fax +44 1227 762 811
>
>> Mobile: +44 77 96 44 7184
>
>> Email:
>
>> Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
>
>> Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
>
>> Entrust key validation string: MLJ9-DU5T-HV8J
>
>> PGP Key ID is 0xBC238DE5
>
>>
>
>> *****************************************************************
>
>>
>
--
*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
School of Computing, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email:
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5
*****************************************************************
