Difference between revisions of "Projects/KerberosInSAML"
(→Background) |
(→Background) |
||
| 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. |
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. |
| − | + | 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. |
|
| − | |||
| − | 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== |
||
Revision as of 14:04, 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. (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.
