[OGSA-AUTHZ] Comments: Use of SAML to Retrieve Authorization Credentials

Mon Sep 15 23:17:26 CDT 2008

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

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