Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
Basics
Technical
Logistics
Basics
Technical
Logistics
Description
None
Environment
None
Activity
Scott Cantor
January 30, 2017 at 3:08 PM
(edited)
Summary of the issue since Tom was interested in taking it.
If you authenticate yourself to the IdP with some other IdP (any protocol), the IdP is supposed to attach the name of that IdP into the assertions it issues in the AuthnStatement as a signal to the SPs that a proxy was used. (That's almost quaint, proxies are so assumed now that I'm not sure why anyone even cares anymore. You'd be as likely to need to tell somebody you didn't use one.)
Since this is part of the authentication process, it has to be stored inside the AuthenticationResult object because that's what gets stored in your session and recovered later for SSO. I would create a ProxyAuthenticationPrincipal and store each upstream proxy name inside one in a list. You have to save them all off ordered and store them in one Principal because the Principal collections aren't ordered in a Java Subject. That also means a bit of work to create a custom PrincipalSerializer to allow our framework to save it off, but it's nothing much, just saving it as a JSON array.
Having done that, the action bean's easy, just inserts into the SAML2 SSO flow and checks the Subject in the SubjectContext for that principal type and inserts the data.
Lastly, we need a way to tunnel the data in from an External authn component or via RemoteUser, by defining an attribute in the External authn interface definition for passing back in this List, and then in RemoteUser allowing it to be pulled in from a header.
Summary of the issue since Tom was interested in taking it.
If you authenticate yourself to the IdP with some other IdP (any protocol), the IdP is supposed to attach the name of that IdP into the assertions it issues in the AuthnStatement as a signal to the SPs that a proxy was used. (That's almost quaint, proxies are so assumed now that I'm not sure why anyone even cares anymore. You'd be as likely to need to tell somebody you didn't use one.)
Since this is part of the authentication process, it has to be stored inside the AuthenticationResult object because that's what gets stored in your session and recovered later for SSO. I would create a ProxyAuthenticationPrincipal and store each upstream proxy name inside one in a list. You have to save them all off ordered and store them in one Principal because the Principal collections aren't ordered in a Java Subject. That also means a bit of work to create a custom PrincipalSerializer to allow our framework to save it off, but it's nothing much, just saving it as a JSON array.
Having done that, the action bean's easy, just inserts into the SAML2 SSO flow and checks the Subject in the SubjectContext for that principal type and inserts the data.
Lastly, we need a way to tunnel the data in from an External authn component or via RemoteUser, by defining an attribute in the External authn interface definition for passing back in this List, and then in RemoteUser allowing it to be pulled in from a header.
That's about it.