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

[David Chadwick]

Hi Tom

Tom Scavo wrote:
> On Tue, Sep 16, 2008 at 12:17 AM, David Chadwick
> <d.w.chadwick at 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.
> 
> http://wiki.oasis-open.org/security/SamlHoKWebSSOProfile

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

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