Projects/SAMLInKerberos

2009-10-28T00:16:54Z

Hbhotz: /* KRB5_AUTHDATA_SAML */

{{project-early}}

<includeonly>[[Category: early stage projects]]</includeonly>

==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. 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?

[HBH comment]: I don't think so.

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.

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

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

===Data===

An example SAML assertion follows:

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

K5Wiki - User contributions [en]

Projects/SAMLInKerberos