Comments: Use of SAML to Retrieve Authorization Credentials
Please find attached some comments regarding the "Use of SAML to Retrieve Authorization Credentials." I haven't fully reviewed this document, but these are the comments I can offer at this time. Tom Scavo NCSA
Hi Tom I am informed by David Groep that ideally we should submit our comments to the OGF public comment page, available at http://www.ogf.org/gf/docs/comment.php?id=272 Would you be willing to do this for these comments, or would you like me to? regards David Tom Scavo wrote:
Please find attached some comments regarding the "Use of SAML to Retrieve Authorization Credentials." I haven't fully reviewed this document, but these are the comments I can offer at this time.
Tom Scavo NCSA
------------------------------------------------------------------------
-- ogsa-authz-wg mailing list ogsa-authz-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
-- ***************************************************************** 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://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************
Hi Tom Your final comment is about the inability to prove the presence of the user. Your proposed solution is "Instead of requiring a DN, the name identifier in the query should be generalized to accommodate the entire certificate". Unfortunately I dont believe that this solves anything, because a certificate is generally publicly available information that can be copied and used by anyone at any time. If by certificate, you mean the end entity certificate, then this is typically valid for a year, so an untrustworthy PEP could use this for a year to query the AA at will. If the certificate is a proxy certificate, or other short lived certificate, which is only valid for a short period of time, say a day, then in this case it significantly shortens the period for abuse. But it still does not guarantee that i) the user is currently using the PEP ii) it is the correct PEP that is making the query (since certificates can be copied by anyone). Furthermore, if a proxy certificate chain is transferred by the PEP to the AA, then you are increasing the processing effort of the AA to determine who the user is, since it has to validate the entire chain of certificates and then remove the trailing RDNs. So I am not convinced that this is an adequate solution to technically remove the need for the AA to trust the PEP. I believe that trust in the PEP is adequate for most usage scenarios. regards David Tom Scavo wrote:
Please find attached some comments regarding the "Use of SAML to Retrieve Authorization Credentials." I haven't fully reviewed this document, but these are the comments I can offer at this time.
Tom Scavo NCSA
------------------------------------------------------------------------
-- ogsa-authz-wg mailing list ogsa-authz-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
-- ***************************************************************** 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://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************
Hi David, I don't disagree with anything you've said below. To solve the "explicit consent" problem, considerably more work is required than what I've proposed in my comments. Before I go any further with this, the question before the group is: Is this a problem that requires a solution in the first place? I'll make one additional comment along these lines. Suppose the attribute query crosses administrative boundaries, say, between a grid VO and a campus AA, where pre-established trust is minimal. Will a query that includes a declaration of "implicit consent" be sufficient? I don't know the answer to that question but I have a gut feeling the answer is no, which is why I've raised the issue. Tom On Mon, Sep 15, 2008 at 5:39 AM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
Hi Tom
Your final comment is about the inability to prove the presence of the user. Your proposed solution is "Instead of requiring a DN, the name identifier in the query should be generalized to accommodate the entire certificate".
Unfortunately I dont believe that this solves anything, because a certificate is generally publicly available information that can be copied and used by anyone at any time. If by certificate, you mean the end entity certificate, then this is typically valid for a year, so an untrustworthy PEP could use this for a year to query the AA at will. If the certificate is a proxy certificate, or other short lived certificate, which is only valid for a short period of time, say a day, then in this case it significantly shortens the period for abuse. But it still does not guarantee that
i) the user is currently using the PEP ii) it is the correct PEP that is making the query (since certificates can be copied by anyone).
Furthermore, if a proxy certificate chain is transferred by the PEP to the AA, then you are increasing the processing effort of the AA to determine who the user is, since it has to validate the entire chain of certificates and then remove the trailing RDNs.
So I am not convinced that this is an adequate solution to technically remove the need for the AA to trust the PEP. I believe that trust in the PEP is adequate for most usage scenarios.
regards
David
Tom Scavo wrote:
Please find attached some comments regarding the "Use of SAML to Retrieve Authorization Credentials." I haven't fully reviewed this document, but these are the comments I can offer at this time.
Tom Scavo NCSA
------------------------------------------------------------------------
-- ogsa-authz-wg mailing list ogsa-authz-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
--
***************************************************************** 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://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5
*****************************************************************
Hi Tom concerning your comment 1b. X.509 authentication is assumed, I am slightly confused by this one. The whole purpose of the OASIS SAML V2.0 Deployment Profiles for X.509 Subjects is that quote "it specifies how a principal who has been issued an X.509 identity certificate is represented as a SAML Subject, how an assertion regarding such a principal is produced and consumed,..." It would therefore be perverse, would it not, to assume that a principal with an X.059 certificate should use any other method to authenticate to the IDP/AA. Your proposed solution does use the X.509 certificate to authenticate, since you need to be sure that the caller possesses the private key that matches the public key in the certificate. Therefore the AA/IDP does know the DN of the user (providing it trusts the CA that issued the cert). If the AA/IDP does not trust the CA, then the user might as well issue self signed certificates. But the OASIS spec says "has been issued an X.509 certificate" so we can assume that the CA is known and trusted. But what you appear to be concerned about is that the public key and DN in the certificate are unknown to the IDP/AA, therefore the latter is unable to authenticate the caller *as being one of its existing users*, so does not know which attributes to release to him/her. But the IDP/AA can still authenticate the user. It is just that the user is unknown to it. Therefore one solution would be for the CA that issued the presumably short lived certificate with a random DN (if it was a long lived certificate then the AA/IDP could use the DN as its user identifier) to also insert into the certificate the username/identifier of the user that is known to the AA/IDP. In this way the AA/IDP can know that the caller holds the private key, and is known by the particular username in the certificate. Would this solve your problem? regards David Tom Scavo wrote:
Please find attached some comments regarding the "Use of SAML to Retrieve Authorization Credentials." I haven't fully reviewed this document, but these are the comments I can offer at this time.
Tom Scavo NCSA
------------------------------------------------------------------------
-- ogsa-authz-wg mailing list ogsa-authz-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
-- ***************************************************************** 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://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************
Here's the use case I have in mind. Suppose I have an account with a Shibboleth Identity Provider and suppose I want to self-query the IdP for attributes. Consider the following assumptions: - I possess a username/password (it is very unlikely that I possess an X.509 credential trusted by the IdP). - Fact: There is no attribute query handler that ships with the Shib2 IdP that can be used in this scenario. - To my knowledge, there is no existing attribute query client that can self-query a Shib IdP for attributes (e.g., clients that implement the current OGF profile can not be used because few, if any Shib IdPs today support an X.509 PKI). - It is easier to implement/deploy an attribute query client and corresponding attribute query handler based on my existing campus credential (username/password) than it is to implement/deploy a system based on an X.509 PKI. - The attribute assertion retrieved from the IdP MUST be a holder-of-key assertion, in any case. If you agree with these assumptions, you are led to the same solution I outlined in my comments, that is, a client that authenticates via HTTP basic auth or WS-Security Username Token Profile. The SSL/TLS client certificate is indeed a self-signed certificate (or more generally, an untrusted X.509 end-entity certificate) used solely to provide a key that the IdP can bind to the assertion (holder-of-key). Internet2 has submitted a profile to the OASIS SSTC that addresses the above problem for Web SSO. NCSA will submit a profile to the OASIS SSTC that solves the corresponding non-browser use case. This opens the door for the implementation/deployment described above and in the comments. I'm sorry if all of this is untimely, but that's the way it goes, I'm afraid. It didn't occur to me that this might be a possible path forward until Internet2 submitted their profile to OASIS. Comments inline below... Tom Scavo NCSA On Mon, Sep 15, 2008 at 10:50 AM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
concerning your comment 1b. X.509 authentication is assumed, I am slightly confused by this one.
The whole purpose of the OASIS SAML V2.0 Deployment Profiles for X.509 Subjects is that quote "it specifies how a principal who has been issued an X.509 identity certificate is represented as a SAML Subject, how an assertion regarding such a principal is produced and consumed,..."
That addresses the VOMS use case but not the Shibboleth use case, so I would argue that is only half the story.
It would therefore be perverse, would it not, to assume that a principal with an X.059 certificate should use any other method to authenticate to the IDP/AA.
Well, that's the whole point. If you assume the user possesses a trusted X.509 certificate (as in VOMS), then that's one thing, but if you relax that assumption and consider other possible use cases (such as Shibboleth), other profiles present themselves.
Your proposed solution does use the X.509 certificate to authenticate, since you need to be sure that the caller possesses the private key that matches the public key in the certificate. Therefore the AA/IDP does know the DN of the user (providing it trusts the CA that issued the cert). If the AA/IDP does not trust the CA, then the user might as well issue self signed certificates.
That's exactly right. I'm asking you to imagine a client configured for SSL/TLS client authn with a self-signed certificate. In fact, we have implemented just such a client.
But the OASIS spec says "has been issued an X.509 certificate" so we can assume that the CA is known and trusted.
Well, I wrote those words so it's okay for me to say they are just plain wrong :-)
But what you appear to be concerned about is that the public key and DN in the certificate are unknown to the IDP/AA, therefore the latter is unable to authenticate the caller *as being one of its existing users*, so does not know which attributes to release to him/her.
All I'm saying is that the SSL/TLS client certificate does NOT authenticate the user. Instead the user authenticates with his/her existing Shibboleth credentials (username/password).
But the IDP/AA can still authenticate the user. It is just that the user is unknown to it. Therefore one solution would be for the CA that issued the presumably short lived certificate with a random DN (if it was a long lived certificate then the AA/IDP could use the DN as its user identifier) to also insert into the certificate the username/identifier of the user that is known to the AA/IDP. In this way the AA/IDP can know that the caller holds the private key, and is known by the particular username in the certificate. Would this solve your problem?
No, not at all. The goal is to convert my username/password into a signed, holder-of-key SAML assertion. That can be done without introducing an X.509 PKI at the Shibboleth IdP.
Tom Scavo wrote:
Please find attached some comments regarding the "Use of SAML to Retrieve Authorization Credentials." I haven't fully reviewed this document, but these are the comments I can offer at this time.
Tom Scavo NCSA
------------------------------------------------------------------------
-- ogsa-authz-wg mailing list ogsa-authz-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
--
***************************************************************** 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://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5
*****************************************************************
Hi Tom this is becoming somewhat clearer. I see two use cases i) obtaining bearer SAML tokens, in which case the user does not need a certificate, the SSL link is created using the server certificate only, and the user authenticates with his un/pw. In this case the client software connects to the IDP, the SSL encrypted link is established by using the IDP's certificate, the user authenticates over the encrypted link, and a bearer SAML attribute assertion is returned in response. ii) obtaining holder of key SAML tokens, in which case the user does need a certificate (any will do). In this case SSL mutual authentication is used, and both parties have now proven possession of the respective private keys. The user can now send his un/pw over the encrypted link, and after authentication can request a SAML attribute assertion which the IDP can return putting the holder of key certificate ID into it. Tom Scavo wrote:
Here's the use case I have in mind. Suppose I have an account with a Shibboleth Identity Provider and suppose I want to self-query the IdP for attributes. Consider the following assumptions:
- I possess a username/password (it is very unlikely that I possess an X.509 credential trusted by the IdP).
- Fact: There is no attribute query handler that ships with the Shib2 IdP that can be used in this scenario.
I think this is because Shibboleth only works with bearer credentials and web browsers, and I think that i) above needs a different client to a web browser.
- To my knowledge, there is no existing attribute query client that can self-query a Shib IdP for attributes (e.g., clients that implement the current OGF profile can not be used because few, if any Shib IdPs today support an X.509 PKI).
- It is easier to implement/deploy an attribute query client and corresponding attribute query handler based on my existing campus credential (username/password) than it is to implement/deploy a system based on an X.509 PKI.
Dont mix up X.509 PKI and X.509 certificates. SSL and browsers work with X.509 certificates and dont need an X.509 PKI to support them. The whole UK academic community is now using Shibboleth and does not have a X.509 PKI for users (but it does use a PKI for servers and IDPs).
- The attribute assertion retrieved from the IdP MUST be a holder-of-key assertion, in any case.
I certainly prefer this to bearer credentials, but actually holder of key is not essential. Use of PIDs is equally feasible (aka the Liberty Alliance model of SSO and federations)
If you agree with these assumptions, you are led to the same solution I outlined in my comments, that is, a client that authenticates via HTTP basic auth or WS-Security Username Token Profile. The SSL/TLS client certificate is indeed a self-signed certificate (or more generally, an untrusted X.509 end-entity certificate) used solely to provide a key that the IdP can bind to the assertion (holder-of-key).
Internet2 has submitted a profile to the OASIS SSTC that addresses the above problem for Web SSO.
can you send me a link to this please. NCSA will submit a profile to the OASIS
SSTC that solves the corresponding non-browser use case. This opens the door for the implementation/deployment described above and in the comments.
I'm sorry if all of this is untimely, but that's the way it goes, I'm afraid. It didn't occur to me that this might be a possible path forward until Internet2 submitted their profile to OASIS.
I am unclear now what your use case is for GT4, and whether the user has a special purpose client, or a standard web browser, and whether any intervening gateway is involved or not in grid access. regards David
Comments inline below...
Tom Scavo NCSA
On Mon, Sep 15, 2008 at 10:50 AM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
concerning your comment 1b. X.509 authentication is assumed, I am slightly confused by this one.
The whole purpose of the OASIS SAML V2.0 Deployment Profiles for X.509 Subjects is that quote "it specifies how a principal who has been issued an X.509 identity certificate is represented as a SAML Subject, how an assertion regarding such a principal is produced and consumed,..."
That addresses the VOMS use case but not the Shibboleth use case, so I would argue that is only half the story.
It would therefore be perverse, would it not, to assume that a principal with an X.059 certificate should use any other method to authenticate to the IDP/AA.
Well, that's the whole point. If you assume the user possesses a trusted X.509 certificate (as in VOMS), then that's one thing, but if you relax that assumption and consider other possible use cases (such as Shibboleth), other profiles present themselves.
Your proposed solution does use the X.509 certificate to authenticate, since you need to be sure that the caller possesses the private key that matches the public key in the certificate. Therefore the AA/IDP does know the DN of the user (providing it trusts the CA that issued the cert). If the AA/IDP does not trust the CA, then the user might as well issue self signed certificates.
That's exactly right. I'm asking you to imagine a client configured for SSL/TLS client authn with a self-signed certificate. In fact, we have implemented just such a client.
But the OASIS spec says "has been issued an X.509 certificate" so we can assume that the CA is known and trusted.
Well, I wrote those words so it's okay for me to say they are just plain wrong :-)
But what you appear to be concerned about is that the public key and DN in the certificate are unknown to the IDP/AA, therefore the latter is unable to authenticate the caller *as being one of its existing users*, so does not know which attributes to release to him/her.
All I'm saying is that the SSL/TLS client certificate does NOT authenticate the user. Instead the user authenticates with his/her existing Shibboleth credentials (username/password).
But the IDP/AA can still authenticate the user. It is just that the user is unknown to it. Therefore one solution would be for the CA that issued the presumably short lived certificate with a random DN (if it was a long lived certificate then the AA/IDP could use the DN as its user identifier) to also insert into the certificate the username/identifier of the user that is known to the AA/IDP. In this way the AA/IDP can know that the caller holds the private key, and is known by the particular username in the certificate. Would this solve your problem?
No, not at all. The goal is to convert my username/password into a signed, holder-of-key SAML assertion. That can be done without introducing an X.509 PKI at the Shibboleth IdP.
Tom Scavo wrote:
Please find attached some comments regarding the "Use of SAML to Retrieve Authorization Credentials." I haven't fully reviewed this document, but these are the comments I can offer at this time.
Tom Scavo NCSA
------------------------------------------------------------------------
-- ogsa-authz-wg mailing list ogsa-authz-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg --
***************************************************************** 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://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5
*****************************************************************
-- ***************************************************************** 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://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************
On Tue, Sep 16, 2008 at 12:17 AM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
I see two use cases
i) obtaining bearer SAML tokens, in which case the user does not need a certificate, the SSL link is created using the server certificate only, and the user authenticates with his un/pw. In this case the client software connects to the IDP, the SSL encrypted link is established by using the IDP's certificate, the user authenticates over the encrypted link, and a bearer SAML attribute assertion is returned in response.
ii) obtaining holder of key SAML tokens, in which case the user does need a certificate (any will do). In this case SSL mutual authentication is used, and both parties have now proven possession of the respective private keys. The user can now send his un/pw over the encrypted link, and after authentication can request a SAML attribute assertion which the IDP can return putting the holder of key certificate ID into it.
Yes, I think that's a reasonable summary, but personally, I'm not interested in profiling bearer tokens. The security properties of bearer tokens are intolerable in the non-browser use case. We'd be forced to implement targeted assertions, but that means the target Grid SP needs to be known in advance, which is just not feasible in the use cases I have in mind.
Tom Scavo wrote:
- Fact: There is no attribute query handler that ships with the Shib2 IdP that can be used in this scenario.
I think this is because Shibboleth only works with bearer credentials and web browsers, and I think that i) above needs a different client to a web browser.
No, it's because attribute query as implemented in Shibboleth is an adjunct to Web Browser SSO, so the IdP maintains state with regard to the subject of the query. A framework exists to write a standalone attribute query handler (in fact, we did just that in Shibboleth 1.3) but no such handler exists for Shib2 AFAIK.
- To my knowledge, there is no existing attribute query client that can self-query a Shib IdP for attributes (e.g., clients that implement the current OGF profile can not be used because few, if any Shib IdPs today support an X.509 PKI).
- It is easier to implement/deploy an attribute query client and corresponding attribute query handler based on my existing campus credential (username/password) than it is to implement/deploy a system based on an X.509 PKI.
Dont mix up X.509 PKI and X.509 certificates.
I'm not :-) If the SSL/TLS client certificate is to be used as an authentication token, an X.509 PKI is required. This is precisely what I want to avoid.
SSL and browsers work with X.509 certificates and dont need an X.509 PKI to support them. The whole UK academic community is now using Shibboleth and does not have a X.509 PKI for users (but it does use a PKI for servers and IDPs).
I know, and I wouldn't want to approach the UK academic community and ask them to deploy an X.509 PKI for end users, which is why I'm proposing modifications to the profile that do NOT assume such a PKI.
- The attribute assertion retrieved from the IdP MUST be a holder-of-key assertion, in any case.
I certainly prefer this to bearer credentials, but actually holder of key is not essential. Use of PIDs is equally feasible (aka the Liberty Alliance model of SSO and federations)
As I said, I don't personally care to go down that path, but if you'd like to profile something for bearer tokens, that's fine with me.
Internet2 has submitted a profile to the OASIS SSTC that addresses the above problem for Web SSO.
can you send me a link to this please.
http://wiki.oasis-open.org/security/SamlHoKWebSSOProfile
I am unclear now what your use case is for GT4, and whether the user has a special purpose client, or a standard web browser, and whether any intervening gateway is involved or not in grid access.
I can say a few words about this, yes, but note that this is out of scope for the OGF profile we are discussing now. Like VOMS-SAML, we are only profiling the attribute exchange, which results in a signed, holder-of-key SAML assertion at the client. What happens after that is out of scope. That said, there at least three paths we can follow: 1. We can implement WS-Security SAML Token Profile in GT4 (which, as I understand it, is the path that users of VOMS-SAML have taken). 2. We can leverage a WS-Trust STS to convert the SAML token obtained from the AA into an X.509 token usable in the grid. 3. We can bind the SAML token to an X.509 proxy certificate. It is the latter, in fact, that is driving my comments. The SAML token must have appropriate security properties if it is to be bound to a proxy certificate. In particular, the subject confirmation method must be compatible with the proxy. If you've followed the discussion thus far, you'll notice there's a flaw (or at least an omission) in option 3. If the user possesses a username/password only, how does one obtain a trusted proxy certificate (with bound SAML token)? I don't know the best answer to that question, so I'll leave it open for now. Hope this helps, Tom
Hi Tom Tom Scavo wrote:
On Tue, Sep 16, 2008 at 12:17 AM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
I see two use cases
i) obtaining bearer SAML tokens, in which case the user does not need a certificate, the SSL link is created using the server certificate only, and the user authenticates with his un/pw. In this case the client software connects to the IDP, the SSL encrypted link is established by using the IDP's certificate, the user authenticates over the encrypted link, and a bearer SAML attribute assertion is returned in response.
ii) obtaining holder of key SAML tokens, in which case the user does need a certificate (any will do). In this case SSL mutual authentication is used, and both parties have now proven possession of the respective private keys. The user can now send his un/pw over the encrypted link, and after authentication can request a SAML attribute assertion which the IDP can return putting the holder of key certificate ID into it.
Yes, I think that's a reasonable summary, but personally, I'm not interested in profiling bearer tokens. The security properties of bearer tokens are intolerable in the non-browser use case.
I totally agree with you :-) We'd be
forced to implement targeted assertions, but that means the target Grid SP needs to be known in advance, which is just not feasible in the use cases I have in mind.
Tom Scavo wrote:
- Fact: There is no attribute query handler that ships with the Shib2 IdP that can be used in this scenario. I think this is because Shibboleth only works with bearer credentials and web browsers, and I think that i) above needs a different client to a web browser.
No, it's because attribute query as implemented in Shibboleth is an adjunct to Web Browser SSO, so the IdP maintains state with regard to the subject of the query. A framework exists to write a standalone attribute query handler (in fact, we did just that in Shibboleth 1.3) but no such handler exists for Shib2 AFAIK.
- To my knowledge, there is no existing attribute query client that can self-query a Shib IdP for attributes (e.g., clients that implement the current OGF profile can not be used because few, if any Shib IdPs today support an X.509 PKI).
- It is easier to implement/deploy an attribute query client and corresponding attribute query handler based on my existing campus credential (username/password) than it is to implement/deploy a system based on an X.509 PKI. Dont mix up X.509 PKI and X.509 certificates.
I'm not :-) If the SSL/TLS client certificate is to be used as an authentication token, an X.509 PKI is required. This is precisely what I want to avoid.
SSL and browsers work with X.509 certificates and dont need an X.509 PKI to support them. The whole UK academic community is now using Shibboleth and does not have a X.509 PKI for users (but it does use a PKI for servers and IDPs).
I know, and I wouldn't want to approach the UK academic community and ask them to deploy an X.509 PKI for end users, which is why I'm proposing modifications to the profile that do NOT assume such a PKI.
- The attribute assertion retrieved from the IdP MUST be a holder-of-key assertion, in any case. I certainly prefer this to bearer credentials, but actually holder of key is not essential. Use of PIDs is equally feasible (aka the Liberty Alliance model of SSO and federations)
As I said, I don't personally care to go down that path, but if you'd like to profile something for bearer tokens, that's fine with me.
Internet2 has submitted a profile to the OASIS SSTC that addresses the above problem for Web SSO. can you send me a link to this please.
thanks for this link
I am unclear now what your use case is for GT4, and whether the user has a special purpose client, or a standard web browser, and whether any intervening gateway is involved or not in grid access.
I can say a few words about this, yes, but note that this is out of scope for the OGF profile we are discussing now. Like VOMS-SAML, we are only profiling the attribute exchange, which results in a signed, holder-of-key SAML assertion at the client. What happens after that is out of scope.
That said, there at least three paths we can follow:
1. We can implement WS-Security SAML Token Profile in GT4 (which, as I understand it, is the path that users of VOMS-SAML have taken).
2. We can leverage a WS-Trust STS to convert the SAML token obtained from the AA into an X.509 token usable in the grid.
3. We can bind the SAML token to an X.509 proxy certificate.
It is the latter, in fact, that is driving my comments. The SAML token must have appropriate security properties if it is to be bound to a proxy certificate. In particular, the subject confirmation method must be compatible with the proxy.
If you've followed the discussion thus far, you'll notice there's a flaw (or at least an omission) in option 3. If the user possesses a username/password only, how does one obtain a trusted proxy certificate (with bound SAML token)? I don't know the best answer to that question, so I'll leave it open for now.
The answer is, he does not need to, if the SAML tokens are signed by the trusted AA. If you use Attribute Based Access Controls, then the identifier of the user (ie. the DN from the proxy cert) is irrelevant. All you need are the valid attributes of the user that can be used in the authz decision making. You have these from the signed SAML assertions, which state that the holder of key Z has the following attributes. The CVS will happily validate these SAML attribute assertions against its policy rules for who are trusted AAs (using the OGSA-Auth WSTrust profile). You can in fact include multiple SAML assertions from multiple IDPs in the X.509 proxy if you want to (and copy these into the WS-Trust message). The GT4 PEP knows that the user is the holder of the key that issued the proxy certificate, so the attributes belong to him. You can even use a self signed EE certificate if you want to, since it is possession of the private key that is important, not trust in the DN. And you can get the user to sign the request message to GT4 if signing of the certificate is not sufficient for you. So forget about having a trusted DN, its irrelevant in ABAC. (This is another good reason for moving on from gridmap files :-) regards David
Hope this helps, 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://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************
On Tue, Sep 16, 2008 at 11:39 AM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
Tom Scavo wrote:
If the user possesses a username/password only, how does one obtain a trusted proxy certificate (with bound SAML token)? I don't know the best answer to that question, so I'll leave it open for now.
The answer is, he does not need to, if the SAML tokens are signed by the trusted AA.
If you use Attribute Based Access Controls, then the identifier of the user (ie. the DN from the proxy cert) is irrelevant. All you need are the valid attributes of the user that can be used in the authz decision making. You have these from the signed SAML assertions, which state that the holder of key Z has the following attributes. The CVS will happily validate these SAML attribute assertions against its policy rules for who are trusted AAs (using the OGSA-Auth WSTrust profile). You can in fact include multiple SAML assertions from multiple IDPs in the X.509 proxy if you want to (and copy these into the WS-Trust message). The GT4 PEP knows that the user is the holder of the key that issued the proxy certificate, so the attributes belong to him. You can even use a self signed EE certificate if you want to, since it is possession of the private key that is important, not trust in the DN. And you can get the user to sign the request message to GT4 if signing of the certificate is not sufficient for you. So forget about having a trusted DN, its irrelevant in ABAC. (This is another good reason for moving on from gridmap files :-)
Here, here! :-) Thanks for letting me explain all that, David. Tom
participants (2)
-
David Chadwick -
Tom Scavo