Difference between revisions of "Projects/KerberosInSAML"
From K5Wiki
< Projects
(→Background) |
|||
Line 5: | Line 5: | ||
==Background== |
==Background== |
||
− | Specify and implement a means for embedding Kerberos tickets in SAML assertions. |
||
+ | 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). |
||
+ | |||
+ | 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:13, 1 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 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).
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.