Projects/SAMLInKerberos - Revision history

Lukeh: /* Transitive trust */

2009-11-05T17:17:24Z

‎Transitive trust

Lukeh: /* SAML-based S4U */

2009-11-05T17:06:58Z

‎SAML-based S4U

Lukeh: /* SAML-based S4U */

2009-11-05T17:06:26Z

‎SAML-based S4U

Lukeh: /* Transitive trust */

2009-11-05T17:04:29Z

‎Transitive trust

Lukeh: /* KDC as IdP */

2009-11-05T17:03:57Z

‎KDC as IdP

Lukeh: /* KRB5_AUTHDATA_SAML */

2009-11-05T17:01:08Z

‎KRB5_AUTHDATA_SAML

Lukeh: /* Transitive trust */

2009-11-02T11:01:13Z

‎Transitive trust

Lukeh: /* Transitive trust */

2009-11-02T10:03:04Z

‎Transitive trust

Lukeh: /* Transitive trust */

2009-11-01T23:01:50Z

‎Transitive trust

Lukeh: /* Transitive trust */

2009-10-31T15:22:08Z

‎Transitive trust

@@ Line 58: / Line 58: @@
 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.
-To further reduce the dependence on PKI, the IdP could sign assertions with a shared secret known to it and the KDC. In this case the KDC does not need to be configured for PKI to vouch for the assertion, it simply needs to know the SAML authority service principal is trusted. The service must then use S4U2Self to verify the assertion (because it does not know the IdP's secret key). An alternative might be for the IdP to perform S4U2Self (or S4U2Proxy) on behalf of the client and return an AP-REQ (with a ticket containing the real assertion) as the "assertion". This provides privacy protection of the assertion and preserves the property of the service not needing to contact a third-party to verify the assertion, at the expense of distorting the Kerberos authentication model somewhat.
+To further reduce the dependence on PKI, the IdP could sign assertions with a shared secret known to it and the KDC. In this case the KDC does not need to be configured for PKI to vouch for the assertion, it simply needs to know the SAML authority service principal is trusted. The service must then use S4U2Self to request the KDC verify the assertion (because it does not know the IdP's secret key). An alternative might be for the IdP to perform S4U2Self (or S4U2Proxy) on behalf of the client and return an AP-REQ (with a ticket containing the real assertion) as the "assertion". This provides privacy protection of the assertion and preserves the property of the service not needing to contact a third-party to verify the assertion, at the expense of distorting the Kerberos authentication model somewhat.
 ===SAML-based S4U===

@@ Line 73: / Line 73: @@
 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.
-Note: in the case of S4U2Proxy, we rely on KRB5SignedData to protect the evidence ticket from server forgeries. If we wanted a solution that didn't require this, we could add a TGS signature to the assertion (although it seems there can only be one XML signature, so somehow we would need to sign the first signature itself).
+Note: in the case of S4U2Proxy, we rely on KRB5SignedData to protect the evidence ticket from server forgeries. We could add a TGS signature to the assertion, instead.
 Further note: [MS-SFU] uses a AS referrals to locate the canonical realm of a user or certificate before performing a S4U2Self request. We will require the client to use SAML name mapping for the case that the subject is not a Kerberos principal name, if they want a real Kerberos principal in the returned ticket.

@@ Line 65: / Line 65: @@
 * a well known principal name is used as the S4U2Self client principal
-* the assertion is submitted in the KDC-REQ authorisation data
+* the assertion is submitted as enc-authorization-data in the KDC-REQ-BODY
 (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.)

@@ Line 43: / Line 43: @@
 * 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. To the application, this has identical semantics to the first approach: the issue is whether the PKI needs to be deployed to each Kerberos service or not. (See below for another approach that avoids deploying PKI to the KDC. Alternatively, a KDC that supports PKINIT could also sign assertions with its private key, but for the purpose of this discussion I'll consider PKI-less SAML as a desirable.)
+The assertion may be submitted in the TGS-REQ as enc-authorization-data. The KDC will copy the assertion into the resulting ticket, adding its own signature if it can vouch for it. To the application, this has identical semantics to the first approach: the issue is whether the PKI needs to be deployed to each Kerberos service or not. (See below for another approach that avoids deploying PKI to the KDC. Alternatively, a KDC that supports PKINIT could also sign assertions with its private key, but for the purpose of this discussion I'll consider PKI-less SAML as a desirable.)
 There are some interesting things that can come out of this. For example, consider the following:

@@ Line 30: / Line 30: @@
 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.
-Note: this will probably go away in a future iteration of this project, in favour of secret-key based trust with Shibboleth.
+Note: this will go away in a future iteration of this project, in favour of trust relationships with third-party IdPs.
 ===SAML GSS Naming Extensions===

← Older revision		Revision as of 17:01, 5 November 2009
Line 19:		Line 19:
	* the Issuer contains the TGS name		* the Issuer contains the TGS name

−	(Note: KDC-issued assertions may be deprecated.)
		+	The assertion may end up in the ticket in four ways:
		+
		+	* issued by the KDC, in the case the KDC is an IdP (or colocated with one)
		+	* submitted as enc-authorization-data by the IdP in a S4U request
		+	* submitted as enc-authorization-data by the client in a normal TGS request
		+	* submitted as enc-authorization-data by the service in a S4U request

	===KDC as IdP===		===KDC as IdP===