This is a reminder that WG last call for both "Attributes used in OGSA Authorization" and "Use of SAML for OGSA Authorization" ends next Monday (Jan 10th). Please see my previous messages in the archive for details: http://www-unix.gridforum.org/mail_archive/ogsa-authz/2004/12/msg00000.html http://www-unix.gridforum.org/mail_archive/ogsa-authz/2004/12/msg00001.html Von
WG Last Call on the two documents is now closed. Further comments can be raised during the public comment period. I believe the only comments to be addressed are Dane's. I will respond to those shortly with suggested changes and put out a new document. http://www-unix.gridforum.org/mail_archive/ogsa-authz/2005/01/msg00001.html (Markus, I believe your comment was addressed by Sassa, please correct me if I am mistaken.) Von Von Welch writes (15:42 January 2, 2005):
This is a reminder that WG last call for both "Attributes used in OGSA Authorization" and "Use of SAML for OGSA Authorization" ends next Monday (Jan 10th).
Please see my previous messages in the archive for details:
http://www-unix.gridforum.org/mail_archive/ogsa-authz/2004/12/msg00000.html http://www-unix.gridforum.org/mail_archive/ogsa-authz/2004/12/msg00001.html
Von
Hi All, Please find my comments on the SAML AuthZ Service Document in the below: 1. 5.1 Element <ExtendedAuthorizationDecisionQuery> Request Signed Element - How the client should behave if it gets unsigned response although it has requested signed one? - Does a client has a free choice for the behavior? ie. A client may ignore the response if it isn't signed even if it has requested a signed response. 2. 6.1.1 NameIdentifier Element - the NameQualifier element is open for the use by applications? IMO, it is good to make it open for application usage 3. 6.1.2 SubjectConfirmation Element - Does the confirmationMethod still be set to http://www.gridforum.org/ogsa-authz/saml/2004/01/am/gsi? even if the subject confirmation method contains X509 Id cert. - How a responder (authz svc) should behave if the data of a subject is supplied in the SubjectConfirmation Element? Is it required to validate the data? 4. 6.1.4 Action Elements - I think it would be better to define the string representation more specific. The QName of the operation would be better. Hope it isn't late, Takuya Mori ---- Takuya Mori
Takuyi, Thank you for the comments. Yes, the document is still working its way through the process and there will be time to address them. Von Takuya Mori writes (21:35 March 13, 2005):
Hi All,
Please find my comments on the SAML AuthZ Service Document in the below:
1. 5.1 Element <ExtendedAuthorizationDecisionQuery> Request Signed Element - How the client should behave if it gets unsigned response although it has requested signed one? - Does a client has a free choice for the behavior? ie. A client may ignore the response if it isn't signed even if it has requested a signed response.
2. 6.1.1 NameIdentifier Element - the NameQualifier element is open for the use by applications? IMO, it is good to make it open for application usage
3. 6.1.2 SubjectConfirmation Element - Does the confirmationMethod still be set to http://www.gridforum.org/ogsa-authz/saml/2004/01/am/gsi? even if the subject confirmation method contains X509 Id cert. - How a responder (authz svc) should behave if the data of a subject is supplied in the SubjectConfirmation Element? Is it required to validate the data?
4. 6.1.4 Action Elements - I think it would be better to define the string representation more specific. The QName of the operation would be better.
Hope it isn't late, Takuya Mori
---- Takuya Mori
Takuya, Apologies for the slow response to your comments. My responses are embedded below. Von Takuya Mori writes (21:35 March 13, 2005):
Hi All,
Please find my comments on the SAML AuthZ Service Document in the below:
1. 5.1 Element <ExtendedAuthorizationDecisionQuery> Request Signed Element - How the client should behave if it gets unsigned response although it has requested signed one? - Does a client has a free choice for the behavior? ie. A client may ignore the response if it isn't signed even if it has requested a signed response.
I think it ultimately up to the client in this case. I've added the following line to the end of the paragraph: An entity receiving an unsigned response when they requested a signature SHOULD disregard it, but MAY choose to use it depending on the application context.
2. 6.1.1 NameIdentifier Element - the NameQualifier element is open for the use by applications? IMO, it is good to make it open for application usage
My understanding from speaking to those in the SAML community is that the NameQualifier field in underspecified and its best to avoid it as many implementation don't have appropriate tooling for dealing with it. We don't talk about the NameQualifier at the moment. It's not clear to me it's a good idea to introduce it at this point.
3. 6.1.2 SubjectConfirmation Element - Does the confirmationMethod still be set to http://www.gridforum.org/ogsa-authz/saml/2004/01/am/gsi? even if the subject confirmation method contains X509 Id cert.
Good question. I'm inclined to say that if no proxy certificate was involved in the authentication it SHOULD be marked as standard X509, but leave the door open for implementatins to mark it as GSI if they don't distinguish between EEC and PCs. My proposed text: <quote> If the subject was authenticated using a Proxy Certificates, the ConfirmationMethod element MUST contain the following URI: http://www.gridforum.org/ogsa-authz/saml/2004/01/am/gsi If the subject was authenticated using a standard X.509 Identify Certificates, the ConfirmationMethod element SHOULD contain the following URI (as defined by [SAML]), however it MAY contain the URI for Proxy Certificate authentication in the event an implementation does not distinguish between the two. URI: urn:oasis:names:tc:SAML:1.0:am:X509-PKI </quote>
- How a responder (authz svc) should behave if the data of a subject is supplied in the SubjectConfirmation Element? Is it required to validate the data?
I assume you mean if the data was NOT supplied. It's not required and it's presence is a SHOULD not a MUST. So I think it's fairly clear a client can't rely on it being there.
4. 6.1.4 Action Elements - I think it would be better to define the string representation more specific. The QName of the operation would be better.
Let me ask our implementors and see what they have done. Von
Hope it isn't late, Takuya Mori
---- Takuya Mori
Von Welch wrote:
4. 6.1.4 Action Elements - I think it would be better to define the string representation more specific. The QName of the operation would be better.
Let me ask our implementors and see what they have done.
From the PDP side of things, we will accept any string, and this string will be contained in the Authz policy governing access to the resource (e.g. it could be read, write, delete etc.) But the PDP does not actually care how the string was obtained or what it means, since it simply compares a presented value with a value in the policy. But clearly from a user's perspective the string must mean something, and from the PEP's perspective it needs to know where to get the string from to pass to the PDP. Therefore a sensible meaning would indeed be the name of the operation being requested by the user. Note that in version 2 of the protocol we are planning to pass operation arguements as well, so it might be better to state that what will be passed (in v2) is the name of the operation and its arguments. regards David
Von
Hope it isn't late, Takuya Mori
---- Takuya Mori
-- ***************************************************************** PLEASE NOTE NEW CONTACT DETAILS AS OF 1 JAN 2005 David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NZ 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 *****************************************************************
Sounds like right now GT is passin just the operation without qualifier. I believe the right thing to do here is leave it as operation name for now, but indicate it should include the namespace in future version of the protocol. Von David Chadwick writes (20:04 May 18, 2005):
Von Welch wrote:
4. 6.1.4 Action Elements - I think it would be better to define the string representation more specific. The QName of the operation would be better.
Let me ask our implementors and see what they have done.
From the PDP side of things, we will accept any string, and this string will be contained in the Authz policy governing access to the resource (e.g. it could be read, write, delete etc.) But the PDP does not actually care how the string was obtained or what it means, since it simply compares a presented value with a value in the policy.
But clearly from a user's perspective the string must mean something, and from the PEP's perspective it needs to know where to get the string from to pass to the PDP. Therefore a sensible meaning would indeed be the name of the operation being requested by the user.
Note that in version 2 of the protocol we are planning to pass operation arguements as well, so it might be better to state that what will be passed (in v2) is the name of the operation and its arguments.
regards
David
Von
Hope it isn't late, Takuya Mori
---- Takuya Mori
--
***************************************************************** PLEASE NOTE NEW CONTACT DETAILS AS OF 1 JAN 2005
David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NZ 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
*****************************************************************
participants (3)
-
David Chadwick -
Takuya Mori -
Von Welch