[OGSA-AUTHZ] Next Telecon

[David Chadwick]

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 at 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

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