Hi Tom answers below. Old bits cut out. Tom Scavo wrote:
I think the PEP needs to (optionally) provide the following additional data to the context handler (who in turn passes it on to the CVS):
- the unique identifier (entityID) of the Identity Provider that exposes the AA
Now why would that be important?
The entityID is the key to the SAML metadata file.
At the conceptual level that we are talking about in this document there is no such thing as a SAML metadata file. That will come later when we map onto actual protocols. The concept of metadata or config data can be talked about however, and at this level all that is needed is a way of finding out how to contact the AA in order to get the user's credentials.
A complete metadata description of the AA will be found in metadata. Admittedly, the location endpoint of the AA is important, but it is not the only piece of metadata of interest.
Actually it is. If you do a complete analysis of the necessary interactions and data that is needed, all an AA needs to know is who the SP recipient is. All that an SP needs to know is how to contact the AA and optionally which attributes to ask for (by default it can ask for all of them that it is allowed to have).
We have included the latter in the existing SAML1.1 profile, as a URL, and can add it to the current spec as well.
What "existing SAML1.1 profile" are you referring to?
GFD.66 Use of SAML for OGSI Authorization the previous deliverable from the WG
- the SAML Subject to use as a query subject
this is conceptually the authenticated name in the diagrams.
Is the "authenticated name" referred to in the diagram the DN from the certificate?
The document does not go into such detail. In fact, in an X.509 PKC context all the subject alt names are authenticated names. If so, this *could* be used as the NameIdentifier in the
query, but more generally, the issuer of the certificate may want to provide an alternate SAML Subject. In particular, the Format of this Subject may be something other than X509SubjectName.
Again, the conceptual document is not really concerned with the formats of messages. This will come later in the protocol specs.
It can be encoded as a SAML Subject if you wish. This is just detail.
No, not quite. If the Grid SP needs to query, it should first look in Subject Alt Name for a SAML Subject. If it doesn't find one, it should fall back on X509SubjectName.
This is implementation details. In the general case, you cannot assume that an X.509 PKC will be used for authentication. I know that it always is in GT, but in other implementations Kerberos or un/pw might be acceptable.
Yes, this is what I already use in the draft profiles published earlier this year
Then why do we need a new profile? Can't we just use the "SAML 2.0 profile of XACML v2.0"?
I think you will find that some guidelines in addition to the above will be useful. Furthermore, if you want to combine protocols 1 and 3, or use pull mode instead of push mode, some more information will be needed. regards David
Tom
-- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, 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://sec.cs.kent.ac.uk Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************