Difference between revisions of "Projects/KerberosInSAML"
(→Background) |
(→Background) |
||
| Line 5: | Line 5: | ||
==Background== |
==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][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. |
||
Revision as of 13:54, 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].
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.
