Open Grid Forum


Community Practice

Archived Comments



OGF Public Comments

Public comments are a very important part of the OGF document approval process.  Through public comments, documents are given scrutiny by people with a wide range of expertise and interests. Ideally, a OGF document will be self-contained, relying only on the other documents and standards it cites to be clear and useful.  Public comments of any type are welcomed, from small editorial comments to broader comments about the scope or merit of the proposed document.  The simple act of reading a document and providing a public comment that you read it and found it suitable for publication is very useful, and provides valuable feedback to the document authors.

Thank you for making public comments on this document!

Comments for Document: Use of SAML to retrieve Authorization Credentials
Author(s):V. Venturi, T. Scavo, D. Chadwick
Public Comment End:2 Oct, 2008

To make anonymous comments, please use 'anonymous' and 'guest' as the un/pw.


Posted by: dwchadwick 2008-09-15 02:32:18Indicating Using Consent
One of the issues with the third party query mode, is how does the AA
know that the user has issued consent for his attributes to be retrieved
by the grid PEP.

I propose that we insert the Consent parameter (see Section 3.2.1 and
8.4 of SAML Core) into the third party query with a value of Implicit.
The fact that the user has initiated the grid job request, causing the
PEP to pull his attributes, implies that he wants his attributes to be
retrieved so that his job can run (otherwise he would get an
authorisation failure message response). It therefore seems perfectly
reasonable for the PEP to insert the Implicit Consent parameter into the
request to the AA

Posted by: trscavo 2008-09-15 08:03:43Comments: Use of SAML to Retrieve Authorization Credentials
Comments: Use of SAML to Retrieve Authorization Credentials

The specification [OGFSAML] profiles the following two use cases:

Case 1. The requester is the subject
Case 2. The requester is acting on behalf of the subject

In case 1, the following issues have been identified:

Issue 1a. Unable to bind the SAML token to a proxy certificate
Issue 1b. X.509 authentication is assumed
Issue 1c. Holder-of-key subject confirmation is not well defined

Likewise in case 2, the following issues have been identified:

Issue 2a. Unable to prove the presence of the subject

We consider each of these issues below.

Issue 1a. Unable to bind the SAML token to a proxy certificate

The first SAML assertion listed in Appendix B has the following element:



This SAML assertion can not be bound to an X.509 proxy certificate since the subject of the assertion can not be confirmed. The value of the element above is the user's X.509 end-entity certificate (EEC) but since the user authenticates with a proxy certificate, the user proves possession of the wrong private key. Thus the subject is not confirmed and the relying party SHOULD discard the enclosing assertion.

So that the assertion may be bound to an X.509 proxy certificate, the identity provider should bind the DN of the EEC to the element:


Now, since the subject of the EEC is the same as the subject of the proxy certificate, authentication with the proxy certificate simultaneously confirms the SAML subject.

This suggests the following attribute query (which does not agree with the published specification):



Note that the above query has a element but no element (which is the exact opposite of that specified in [SAMLX509Subject]).

Issue 1b. X.509 authentication is assumed

The profile [SAMLX509SelfQry] assumes that the user authenticates to the SAML Attribute Authority (AA) with an X.509 credential, which is too restrictive. The user should be able to authenticate with any type of credential, even a username/password, as long as the requirement for a holder-of-key assertion is satisfied.

To permit flexibility in the authentication token used to authenticate to the AA, the specification needs to separate the authentication step from the proof of possession. The following requirements achieve the required separation:

* The user MUST authenticate to the AA, but the means by which this authentication takes place are unspecified
* The user MUST present an X.509 certificate to the AA
* The user MUST prove possession of the private key corresponding to the public key bound to the certificate

If the user authenticates with a trusted X.509 certificate, all of these requirements are satisfied, but the above reformulation of the requirements permits other scenarios as well. For example, suppose that the user authenticates to the AA with a username/password using HTTP basic auth or WS-Security Username Token Profile. Suppose further that the request is issued over SSL/TLS using an untrusted client certificate. This proves possession of the corresponding private key, but since the client certificate is untrusted, it does not authenticate the user. However, the client certificate still can (and should) be bound to the assertion by the AA.

Issue 1c. Holder-of-key subject confirmation is not well defined

The issuing and processing of holder-of-key SAML assertions is not well defined in [SAMLX509]. Moreover, such requirements are not specified in SAML Core, so there is nothing to rely on. (The OASIS SSTC is considering this issue [SAMLHoK] at this time.)

Issue 2a. Unable to prove the presence of the subject

Since the profile [SAMLX509] specifies that the name identifier in the query is a DN, there is no way to prove user presence at the Grid SP. Without proof of user presence, an SP could phish for attributes using the globally unique, persistent DN.

Note that this issue does not exist for the self-query (of which traditional VOMS is an example), rather the problem involves a query where the requester is acting on behalf of the subject. In that case, the subject must pass some piece of information to the Grid SP that the SP can forward to the AA.

I'm convinced we've specified the name identifier in the query (DN) incorrectly. The requester has to prove user presence and it seems clear that more than a DN is needed. Since the user is authenticating to the Grid SP with an X.509 certificate, the obvious conclusion is that 1) there is some piece of info in the certificate that proves user presence, and 2) the SP passes the complete cert (not just the DN) to the AA.

I'll propose the following "patch" to our profile:

Instead of requiring a DN, the name identifier in the query should be generalized to accommodate the entire certificate (without excluding the possibility of a naked DN in those situations where it is warranted). This can be done using , something like this:


where KeyIdentifierType is defined as follows:

This new name identifier type accommodates either a DN or a certificate. In addition to proving user presence at the Grid SP, using a certificate in this way has the extra added benefit that it avoids potential DN string matching at the AA, which in and of itself is almost sufficient reason to pass a certificate instead of a DN.


[OGFSAML] V. Venturi, T. Scavo, D. Chadwick. Use of SAML to retrieve Authorization Credentials. See

[SAMLX509] T. Scavo. SAML V2.0 Deployment Profiles for X.509 Subjects. OASIS Committee Specification, 27 March 2008. Document ID sstc-saml2-x509-profiles-deploy-cs-01. See

[SAMLX509Subject] X.509 SAML Subject Profile. See section 2 of [SAMLX509]

[SAMLX509Query] SAML Attribute Query Deployment Profile for X.509 Subjects. See section 3 of [SAMLX509]

[SAMLX509SelfQry] SAML Attribute Self-Query Deployment Profile for X.509 Subjects. See section 4 of [SAMLX509]

[SAMLHoK] SAML V2.0 Holder-of-Key Assertion Profile. See

> login   RSS RSS Contact Webmaster

OGFSM, Open Grid ForumSM, Grid ForumSM, and the OGF Logo are trademarks of OGF