logo_kerberos.gif

Difference between revisions of "Projects/KerberosInSAML"

From K5Wiki
Jump to: navigation, search
(→‎Background)
(→‎Specifications)
 
(8 intermediate revisions by the same user not shown)
Line 7: Line 7:
 
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.
  
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].
 +
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.
   
⚫
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).
  
  +
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.
   
−
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.
  
  ⚫
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==
  
==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]http://k5wiki.kerberos.org/w/images/c/c8/Kerberos_in_SAML_WebSSO.png.
  +
  +
  +
  +
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==
  +
  +
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.].
  +
  +
The Kerberos subject confirmation method[http://www.oasis-open.org/apps/org/workgroup/security/download.php/35333/sstc-saml-kerberos-subject-confirmation-method-cd-01.zip].
   
 
==Implementation==
  
==Implementation==

Latest revision as of 14:35, 4 December 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

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][1]. 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. (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.

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

The high-level interaction between the KDC and the SAML2.0 entities in the Web-SSO use-case is shown in the following [diagram]Kerberos_in_SAML_WebSSO.png.


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

The following are the list of Oasis specifications (now in Committee Draft status):

The Kerberos attribute profile [2].

The Kerberos subject confirmation method[3].

Implementation

Open issues

Status

Retrieved from "https://k5wiki.kerberos.org/wiki?title=Projects/KerberosInSAML&oldid=3048"