Re: Telling the PIP where to pull from

[David Chadwick <d.w.chadwick@kent.ac.uk>]

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, sampo@zxidp.org wrote:
> David Chadwick<d.w.chadwick@kent.ac.uk>  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: D.W.Chadwick@kent.ac.uk
>
>> 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: D.W.Chadwick@kent.ac.uk
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

*****************************************************************