Difference between revisions of "Projects/KerberosInSAML"

Revision as of 13:59, 4 December 2009

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.

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.

Architecture

Implementation

Open issues

Status