[OGSA-AUTHZ] New document. WS-TRUST/SAML profile

[David Chadwick]

Hi Yuri

answers to your questions below

Yuri Demchenko wrote:
> Hi David,
> 
> I fully support the idea to define credentials validation service as 
> complimentary to XACML based AuthZ service.

thanks

> 
> It's known that XACML TC keeps strictly from adding attributes 
> validation functionality to the specification.
> 
> This service/functionality is needed and we will support its specification.
> 
> I read both your drafts and have few general and specific questions.
> 
> Most of general questions are related to the terminology and definition 
> of some basic components. Below are some of them.
> 
> 1) I don't know whether it is necessary to introduce in this particular 
> specification, that deals with credentials validation, push and pull 
> models (for attribute I guess?).

this is credential push and pull, not attribute push and pull

> 
> If you want to request attributes based on the authenticated Subject 
>  creds/ID, this is actually Attribute Authority (AA) function. So, why 
> we should embed it into CVS?

I am not doing this. The AA function still exists, as a separate remote 
function. All the CVS is doing is asking the AA to give it the user's 
credentials, which it will then validate according to the local policy, 
and if they are acceptable will return then to the PEP along with the 
other validated attributes.

> 
> Keeping CVS to perform its major function to validate presented 
> credentials/attributes would be more logical.

this is exactly what it is doing. But the credentials may be pushed to 
it (as in VOMS) or pulled by it (as in GridShib)

> 
> 2) in WST/SAML document you have sections "4/5. Request Protocol, 
> Push/Push model" and "6. Response Protocol"
> 
> Is it what you mean that there will be separate request and response 
> protocols respectively? However currently you describe only request and 
> response messages.

The idea is that there is only one response protocol, regardless of 
whether the credentials were pushed or pulled or both.

In the most complex scenario you could have

1. PEP pushes some credentials to the CVS
2. CVS pulls some more credentials from remote AAs
3. CVS responds to PEP with the complete set of validated credentials.

An example of when this is needed is when the user has been delegated a 
credential and only gives this to the PEP. The CVS sees that the 
credential is delegated and then goes to the AA of the delegator to get 
the credential of the delegator. The CVS may then have a complete chain 
of credentials from the user to the trusted root. (The CVS may need to 
go to several AAs if the delegation chain is a long one)



> 
> 3) Can you clarify what is meant by "WS-Trust request protocol message" 
> in section 4?

In section 4.2 it is specifying how the SAML attribute assertions 
(specified in 4.1) are wrapped inside a WS-Trust message to tell the CVS 
what it has to do with them, which is to validate the SAML assertions 
and return a single assertion in XACML format.



> 
> WST specification specifies mechanisms that can be added to other 
> protocols and messages especially WS related and SOAP based.
> 
> 4) I can guess that in section 7 you define a new element 
> <SubjectAttributeReferenceAdvice> but it is not clear if there is no 
> currently available solutions to do intended attributes request based on 
> authenticated Subject ID, e.g. in GridShib to which you refer in  
> Request pull model in section 3.1.


SubjectAttributeReferenceAdvice is actually copied from the existing 
OGSA SAML profile. But if you have an alternative way to do this then I 
am happy to use it. The GridShib interface is actually a Java method 
call so they dont have an equivalent XML protocol for this (but Von and 
Frank can correct me on this if I am wrong)


> 
> 5) In regard to security considerations it should be explained somewhere 
> how you protect CVS response message from possible tampering.

Good point. This should be added to Section 8.

> 
> Should it be signed by CVS or the WST security mechanisms should be used?

We should debate this. I dont have any strong opinions either way 
(except that for performance reasons I prefer SSL :-)


> 
> Other minor and document specific questions and comments I will better 
> provide in a form of revision of your documents.

Many thanks

David

> 
> Regards,
> 
> Yuri
> 
> David Chadwick wrote:
> 
>> Dear All
>>
>> please find attached my first strawman proposal for a profile for 
>> accessing a credential validation service/security token service/PIP.
>>
>> This document is the first of two. The second will be a profile for 
>> XACML for accessing a PDP. As you will read from the attached 
>> document, the input to the CVS is a set of credentials, and the output 
>> is a set of validated XACML attributes ready for input to the PDP. I 
>> look forward to your comments on the above either before or during the 
>> next GGF meeting
>>
>> regards
>>
>> David
>>
>>
>> I have uploaded the attached to gridforge but it does not appear to be 
>> visible to the public yet.
>>
>>
> 
> 

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
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

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