Projects/KerberosInSAML - Revision history

Hardjono: /* Specifications */

2009-12-04T19:35:47Z

‎Specifications

Hardjono: /* Specifications */

2009-12-04T19:35:13Z

‎Specifications

Hardjono: /* Specifications */

2009-12-04T19:34:46Z

‎Specifications

Hardjono: /* Architecture */

2009-12-04T19:28:00Z

‎Architecture

Hardjono: /* Architecture */

2009-12-04T19:18:24Z

‎Architecture

Hardjono at 19:13, 4 December 2009

2009-12-04T19:13:58Z

Hardjono: /* Architecture */

2009-12-04T19:09:17Z

‎Architecture

Hardjono: /* Background */

2009-12-04T19:04:59Z

‎Background

Hardjono: /* Background */

2009-12-04T18:59:35Z

‎Background

Hardjono: /* Background */

2009-12-04T18:54:54Z

‎Background

@@ Line 25: / Line 25: @@
 ==Specifications==
-The following are the list of Oasis specifications (now in Commitee Draft status):
+The following are the list of Oasis specifications (now in Committee Draft status):
 The Kerberos attribute profile [http://www.oasis-open.org/apps/org/workgroup/security/download.php/35332/sstc-saml-attribute-kerberos-cd-01.zip.].
 ==Implementation==

@@ Line 27: / Line 27: @@
 The following are the list of Oasis specifications (now in Commitee Draft status):
-The Kerberos attribute profile [spec][http://www.oasis-open.org/apps/org/workgroup/security/download.php/35332/sstc-saml-attribute-kerberos-cd-01.zip.].
+The Kerberos attribute profile [http://www.oasis-open.org/apps/org/workgroup/security/download.php/35332/sstc-saml-attribute-kerberos-cd-01.zip.].
 ==Implementation==

← Older revision		Revision as of 19:34, 4 December 2009
Line 24:		Line 24:

	==Specifications==		==Specifications==
		+
		+	The following are the list of Oasis specifications (now in Commitee Draft status):
		+
		+	The Kerberos attribute profile [spec][http://www.oasis-open.org/apps/org/workgroup/security/download.php/35332/sstc-saml-attribute-kerberos-cd-01.zip.].
		+
		+	The Kerberos subject confirmation method [spec][http://www.oasis-open.org/apps/org/workgroup/security/download.php/35333/sstc-saml-kerberos-subject-confirmation-method-cd-01.zip]

	==Implementation==		==Implementation==

← Older revision		Revision as of 19:28, 4 December 2009
Line 19:		Line 19:


−	Here
		+	Here it is assumed that in Step-0 (not shown), the Client has first requested access to a service or resource to the SAML2.0 Service provider (SP). As per the SAML.20 Web-SSO use-case, the SP redirects the Client to the SAML2.0 Identity Provider (Idp) which requests that the Client authenticate to the IdP. Since we assume that the Client already has a TGT (via a previous authentication event to the KDC), the Client now requests from the KDC a service-ticket for the IdP (Step-1 and Step-2).
		+
		+	After obtaining the service-ticket , the Client delivers it (AP_REQ message) to the IdP in Step-3. The IdP issues a SAML assertion which states that the Client has been authenticated by the IdP. the Client then returns that SAML assertion to the SP.

	==Specifications==		==Specifications==

← Older revision		Revision as of 19:18, 4 December 2009
Line 15:		Line 15:
	==Architecture==		==Architecture==

−	The high-level interaction between the KDC and the SAML2.0 entities in the Web-SSO use-case is shown in the following diagram.	+	The high-level interaction between the KDC and the SAML2.0 entities in the Web-SSO use-case is shown in the following [diagram]http://k5wiki.kerberos.org/w/images/c/c8/Kerberos_in_SAML_WebSSO.png.

← Older revision		Revision as of 19:13, 4 December 2009
Line 20:		Line 20:

	Here		Here
		+
		+	==Specifications==

	==Implementation==		==Implementation==

← Older revision		Revision as of 19:09, 4 December 2009
Line 14:		Line 14:

	==Architecture==		==Architecture==
		+
		+	The high-level interaction between the KDC and the SAML2.0 entities in the Web-SSO use-case is shown in the following diagram.
		+
		+
		+
		+	Here

	==Implementation==		==Implementation==

@@ Line 9: / Line 9: @@
 Currently there are a number of limitations in using Kerberos for authentication within the SAML2.0 architecture. Previous work in the space of the Web-Services Security (WSS) resulted in the publication of the [WSS Kerberos Token Profile 1.1][http://www.oasis-open.org/committees/download.php/16788/wss-v1.1-spec-os-KerberosTokenProfile.pdf]. This profile primarily addresses the delivery and format of the AP_REQ message within the WSS context.  Although WSS today also supports the carrying of SAML structures, there are no specifications or profiles in SAML2.0 that specifically addresses Kerberos and its usage in SAML2.0.
-This work will cover the following: (i) investigate existing standard SAML.20 use-cases (or profiles), in order to see how Kerberos can be used to provide authentication (and optionally confidentiality) within those use-cases.
+This work will cover the following: (i) investigate existing standard SAML.20 use-cases (or profiles), in order to see how Kerberos can be used to provide authentication (and optionally confidentiality) within those use-cases. (ii) Contributing new specifications to the Oasis SSTC covering aspects of Kerberos support within SAML2.0. (iii) Implement prototypes (using Kerberos) covering one or two important SAML2.0 use-cases.
-The main first use-case is that of SAML2.0 Web Single Sign On (Web-SSO) profile. The idea here is to make the Identity Provider (IdP) a service principal that can validate a service-ticket contained within an AP_REQ message.  After authenticating the client (user), the IdP will then issue a (signed) SAML assertion that identities the Kerberos client principal, and optionally carries the original AP_REQ request (encoded in base64).
+Currently the first use-case being addressed is the SAML2.0 Web Single Sign On (Web-SSO) profile. The idea here is to make the Identity Provider (IdP) a service principal that can validate a service-ticket contained within an AP_REQ message.  After authenticating the client (user), the IdP will then issue a (signed) SAML assertion that identities the Kerberos client principal, and optionally carries the original AP_REQ request (encoded in base64). In this SAML2.0 Web-SSO use case, there is an assumed dependence of the Service Provider (SP) upon the IdP. Thus, the SP is a true relying party.
 ==Architecture==

← Older revision		Revision as of 18:54, 4 December 2009
Line 5:		Line 5:
	==Background==		==Background==

⚫	~~Specify and implement a means for embedding Kerberos tickets in SAML assertions.~~ The main first use-case is that of SAML2.0 Web Single Sign On (Web-SSO) profile. The idea here is to make the Identity Provider (IdP) a service principal that can validate a service-ticket contained within an AP_REQ message. After authenticating the client (user), the IdP will then issue a (signed) SAML assertion that identities the Kerberos client principal, and optionally carries the original AP_REQ request (encoded in base64).
		+	Specify and implement a means for extending (or transferring) trust from a Kerberos service ticket to a SAML assertion. Optionally, include the original AP_REQ message or the service-ticket portion within the SAML assertion.
		+
		+	Currently there are a number of limitations in using Kerberos for authentication within the SAML2.0 architecture. Previous work in the space of the Web-Services Security (WSS) resulted in the publication of the [WSS Kerberos Token Profile 1.1][http://www.oasis-open.org/committees/download.php/16788/wss-v1.1-spec-os-KerberosTokenProfile.pdf].
		+
		⚫	The main first use-case is that of SAML2.0 Web Single Sign On (Web-SSO) profile. The idea here is to make the Identity Provider (IdP) a service principal that can validate a service-ticket contained within an AP_REQ message. After authenticating the client (user), the IdP will then issue a (signed) SAML assertion that identities the Kerberos client principal, and optionally carries the original AP_REQ request (encoded in base64).

	In this SAML2.0 Web-SSO use case, there is an assumed dependence of the Service Provider (SP) upon the IdP. Thus, the SP is a true relying party.		In this SAML2.0 Web-SSO use case, there is an assumed dependence of the Service Provider (SP) upon the IdP. Thus, the SP is a true relying party.