Projects/SAMLInKerberos

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. The assertion is bound to the ticket in the following manner:

• the assertion is signed with the TGT session key
• the assertion contains an AuthnStatement with the authtime as AuthnInstant and the Kerberos AuthnContextClassRef
• the Subject contains the client principal name
• the Issuer contains the TGS name

TBD: using the TGT session key is similar to AD-KDCIssued, but it has the disadvantage that the KDC and server must take care when verifying the signature, because the client will know the session key as soon as the ticket is issued. The server must reject this element if it is included in the authenticator (unless, of course, it can be validated using a different 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 (using OpenSAML). 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

Of course, another approach would be to use FAST or a new variant on the S4U2Self protocol, but for prototyping this may be simplest.

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