[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Telling the PIP where to pull from
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 *****************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]