logo_kerberos.gif

Projects/SAMLInKerberos

From K5Wiki
< Projects
Revision as of 17:54, 29 October 2009 by Lukeh (talk | contribs) (→‎Implementation)

Jump to: navigation, search
This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.



Background

Extend Kerberos to permit the inclusion of a SAML assertion in KDC-issued authorization data.

Architecture

KRB5_AUTHDATA_SAML

A new authorisation data type, KRB5_AUTHDATA_SAML, is defined. This carries a SAML assertion. When issued or vouched for by the KDC, the assertion is bound to a ticket by signing with the TGT session key and adding the Kerberos HoK subject confirmation. This behaviour is similar to AD-KDCIssued, except that XML signatures are used.

Additionally, for assertions issued by the KDC:

  • an AuthnStatement is present containing the authtime as AuthnInstant and the Kerberos AuthnContextClassRef
  • the Subject contains the client principal name
  • the Issuer contains the TGS name

TBD: is there any point in validating the Issuer and AuthnStatement given only the TGS could have signed the assertion with that session key?

KDC as IdP

A new KDC-side authorisation data plugin assembles a SAML assertion from a user's attributes in the directory and signs it. Presently, all attributes not used by the Kerberos LDAP backend itself are propagated into the attribute statement: whilst the use of directory server-side ACLs affords some flexibility, this will be most useful when attributes can be mapped and filtered on a per-deployment and per-service basis.

SAML GSS Naming Extensions

A new GSS naming extensions plugin verifies the above authorisation data and parses it. The attribute statement is then surfaced through GSS naming extensions.

Transitive trust

It would be useful for services to validate assertions that are not issued by the KDC. I propose two mechanisms:

  • the GSS naming extensions plugin supports the verification of public key signatures and some out-of-band mechanism for binding principal names
  • the KDC can vouch for assertions issued by a third-party IdP

The assertion may be submitted in the TGS-REQ. The KDC will copy the assertion into the resulting ticket, optionally adding its own signature if it can vouch for it. The verification code is similar: the issue is whether the PKI needs to be deployed to each Kerberos service or not (although, see below for another approach).

There are some interesting things that can come out of this. For example, consider the following:

  • client authenticates to IdP with Kerberos
  • IdP issues assertion for client
  • client does TGS-REQ for a new TGT, submitting authorisation data

Now, let's first take the case where the KDC doesn't know anything about SAML. It will blindly copy the assertion into the returned TGT. If the service is SAML aware, it can verify the assertion with the IdP's public key and then interrogate the claims with naming extensions. So that gets you an authorisation service decoupled from Kerberos, with similar properties to the PAC.

The disadvantage is that PKI needs to be deployed to each service. If the KDC is SAML-aware, then after validating the ticket-assertion binding it can vouch for the assertion in future service tickets, signing them with the ticket service key. (Indeed, it might use AMA to validate the client authenticated to the IdP with Kerberos.) Regardless, the actual application doesn't need to be aware how the assertion was validated: it simply receives a set of claims it can interrogate with GSS naming extensions.

Of course, there's no reason one needs to use a TGT: the same approach would work for individual service tickets (which offers richer authorisation than treating the realm as a single SP, which negates the possibility to do per-service claims filtering unless the KDC does it itself). But I chose this example for its similarity to DCE and Windows.

Another possibility might be for the assertion to be signed with the service key rather than the KDC key. (Note that for S4U2Proxy, the authorisation data is also protected by the TGS session key in KRB5SignedData.) In this case, an IdP trusted by the KDC can sign assertions without requiring a PKI trust relationship between the IdP and KDC. Of course, this might limit our interoperability with third-party IdPs (but, we can still support PKI, and the implementation cost would not be great). In this case, the signing key provides no binding between the ticket and assertion beyond the fact that the KDC vouched for it, so the authtime and client name bindings are critical.

SAML-based S4U2Self

A variant of S4U2Self that supports identifying users with SAML assertions is proposed. One way would be to leverage the existing S4U2Self protocol exchange, redefining the semantics such that:

  • a well known principal name is used as the S4U2Self client principal
  • the assertion is submitted in the KDC-REQ authorisation data

(This is an abuse of the authorisation data field: a better approach would be to use FAST but I may use the above for prototyping to avoid extensive changes to the KDC and client library whilst prototyping. Unfortunately some architectural changes will be required to support flexible subject mapping.)

In this case, the KDC attempts to bind the assertion in the KDC-REQ authorisation data to the S4U client, rather than the service making the request.

If an assertion is submitted with a S4U2Proxy request, then it should be bound to the evidence ticket client, rather than the service making the request.

Name encoding

When using a SAML assertion to identify a user where the requestor does not know of the Kerberos principal name mapping, it should use the following names. This would be the case during S4U2Self or possibly PKU2U.

Principal names

From draft-zhu-pku2u we import the NULL principal name.

  • The type is KRB_NT_WELLKNOWN
  • The name-string field consists of "WELLKNOWN", "NULL"

Realm names

From draft-ietf-krb-wg-naming we import the wellknown realm type.

  • The realm name is WELLKNOWN:SAML

Implementation

Preliminary code is in the users/lhoward/saml branch, which itself is a branch of the constrained delegation (users/lhoward/s4u2proxy) branch. Most of the code is to be found in src/plugins/authdata/saml_{client,server}.

OpenSAML is assumed to be installed in /usr/local.

KDC authorisation data handling

Pseudo-code (this is still heavily experimental): 

if ( not kdc.req.type != tgs_req || service & no auth data)
  return

authenticated ::= false
assertion ::= tgs_req.authdata.saml
if ( assertion == nil )
{
    assertion ::= tgt.authdata.saml
    authenticated = true
}

if ( assertion != nil )
{
    verify_assertion
    {
        verify_subject_binding
        optionally verify_principal_mapping
        verify_signatures
        verify_constraints
    }
}

if ( assertion == nil && client != nil )
{
    assertion ::= build_assertion_from_kdb()
}

if ( assertion != nil )
{
    if ( authenticated )
    {
        if ( bound_principal is in local realm ) // for S4U2Self referrals
            confirm_subject(assertion.subject, bound_principal)
        sign
    }
    encode
}

Open issues

  • From Henry Hotz: I'm also concerned about interoperability issues. E.g. if there is also a PAC then shouldn't we guarantee a 1-to-1 correspondence between SAML assertions and group memberships? This concern extends to any other authorization data types as well. [LH: RFC 4120 specifies AD-IF-RELEVANT to address this. The auth data is honoured if it is relevant.]

Status

Current status is partial prototype only.

Examples

Testing

The following test shows a service principal acquiring a ticket for bjensen@MIT.DE.PADL.COM and displaying the returned attribute statement via naming extensions: 

Protocol transition tests follow
-----------------------------------

Reading symbols for shared libraries . done
Reading symbols for shared libraries ..... done
Target name:	host/somehost.mit.de.padl.com@MIT.DE.PADL.COM
Target mech:	{ 1 2 840 113554 1 2 2 }
Source name:	bjensen@MIT.DE.PADL.COM
Source mech:	{ 1 2 840 113554 1 2 2 }
Attribute: urn:oid:0.9.2342.19200300.100.1.3 Authenticated Complete
Value: bjensen@padl.com

Attribute: urn:oid:2.5.4.4 Authenticated Complete
Value: Jensen

Attribute: urn:oid:2.5.4.42 Authenticated Complete
Value: Babs

Attribute: urn:oid:2.5.4.3 Authenticated Complete
Value: Babs Jensen

Attribute: urn:oid:2.5.4.20 Authenticated Complete
Value: +1 212 555 1234

Attribute: urn:oid:2.5.4.43 Authenticated Complete
Value: BJ

Data

An example SAML assertion follows: 

<saml:Assertion
  xmlns:saml='urn:oasis:names:tc:SAML:2.0:assertion'
  xmlns:xs='http://www.w3.org/2001/XMLSchema'
  xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
  xmlns:x500='urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500'
  xmlns:ds='http://www.w3.org/2000/09/xmldsig#'
  ID='_3e53282d753b22b3b1273a0895dfd37c'
  Version='2.0'
  IssueInstant='2009-10-26T22:23:27Z'
>
  <saml:Issuer
    Format='urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos'
  >krbtgt/MIT.DE.PADL.COM@MIT.DE.PADL.COM</saml:Issuer>
  <saml:Subject>
    <saml:NameID
      Format='urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos'
    >bjensen@MIT.DE.PADL.COM</saml:NameID>
  </saml:Subject>
  <saml:Conditions
    NotBefore='2009-10-26T22:23:27Z'
    NotOnOrAfter='2009-10-27T22:23:27Z'
  ></saml:Conditions>
  <saml:AuthnStatement
    AuthnInstant='2009-10-26T22:23:27Z'
  >
    <saml:AuthnContext>
      <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos</saml:AuthnContextClassRef>
    </saml:AuthnContext>
  </saml:AuthnStatement>
  <saml:AttributeStatement>
    <saml:Attribute
      NameFormat='urn:oasis:names:tc:SAML:2.0:attrname-format:uri'
      FriendlyName='mail'
      Name='urn:oid:0.9.2342.19200300.100.1.3'
      x500:Encoding='LDAP'
    >
      <saml:AttributeValue>bjensen@padl.com</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute
      NameFormat='urn:oasis:names:tc:SAML:2.0:attrname-format:uri'
      FriendlyName='sn'
      Name='urn:oid:2.5.4.4'
      x500:Encoding='LDAP'
    >
      <saml:AttributeValue>Jensen</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute
      NameFormat='urn:oasis:names:tc:SAML:2.0:attrname-format:uri'
      FriendlyName='givenName'
      Name='urn:oid:2.5.4.42'
      x500:Encoding='LDAP'
    >
      <saml:AttributeValue>Babs</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute
      NameFormat='urn:oasis:names:tc:SAML:2.0:attrname-format:uri'
      FriendlyName='cn'
      Name='urn:oid:2.5.4.3'
      x500:Encoding='LDAP'
    >
      <saml:AttributeValue>Babs Jensen</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute
      NameFormat='urn:oasis:names:tc:SAML:2.0:attrname-format:uri'
      FriendlyName='telephoneNumber'
      Name='urn:oid:2.5.4.20'
      x500:Encoding='LDAP'
    >
      <saml:AttributeValue>+1 212 555 1234</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute
      NameFormat='urn:oasis:names:tc:SAML:2.0:attrname-format:uri'
      FriendlyName='initials'
      Name='urn:oid:2.5.4.43'
      x500:Encoding='LDAP'
    >
      <saml:AttributeValue>BJ</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>
Retrieved from "https://k5wiki.kerberos.org./wiki?title=Projects/SAMLInKerberos&oldid=2861"