Difference between revisions of "Projects/SAMLInKerberos"

Revision as of 17:35, 29 October 2009

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, presently unimplemented, 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.

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.

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.

Open issues

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>

@@ Line 20: / Line 20: @@
 TBD: is there any point in validating the Issuer and AuthnStatement given only the TGS could have signed the assertion with that session key?
-[HBH comment]: I don't think so. [LH: The binding is useful in the delegation case if the assertion is resigned.]
-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.]
 ===KDC as IdP===