Local SSO integration with IdP 5.1.1

Christopher Bongaarts cab at umn.edu
Tue Apr 9 21:11:31 UTC 2024


I'm reexamining the way we use an old SSO system to handle account 
initialization authentication.  It was first developed in the IdP 2 or 3 
days (it was hacked into the initial auth flow mechanism!) and internals 
have changed enough that I might be able to get away with a simpler and 
less kludgy solution.

Use case:  when a user claims their account for the first time, or when 
a user creates a guest account, we don't want to make them immediately 
re-enter the password they just entered (twice) as part of the creation 
process.

Current solution:  our identity system frontend sets a domain cookie 
containing an encrypted structure containing the username, timestamp, 
and some less interesting tidbits.  We have a couple of authentication 
actions that we insert into the authn flow that look for and 
decrypt/verify/unpack the cookie.  If the cookie is valid, we create an 
IdPSession with an AuthenticationResult created from the data in the 
cookie, and let the standard SSO process leverage that.

The bit that gets hacked into authn-flow.xml looks like this:

     <action-state id="AuthenticationSetup">
         <evaluate expression="PopulateAuthenticationContext" />
         <evaluate expression="PopulateSessionContext" />
         <evaluate expression="SetRPUIInformation" />
         <evaluate expression="'proceed'" />

         <transition on="proceed" to="TestForV2SSO" />
     </action-state>

     <!--
         Check for and extract a V2 SSO cookie from v2 IdP, account 
init, guest
         account creation, etc. and create or update a Session with the
         authentication results.
     -->
     <action-state id="TestForV2SSO">
         <!-- pull out data from cookie into subjectContext, throw
              a NoV2SSOResult event if nothing found -->
        <evaluate expression="ExtractV2SSOResults" />
        <evaluate expression="'proceed'" />

        <!-- Ignore any session layer errors at this stage. -->
        <transition to="TestForSession" />
     </action-state>

where ExtractV2SSOResults is a custom Java class that was largely based 
on the built-in ExtractActiveAuthenticationResults.

I can see a few ways to do this and would welcome suggestions on what to 
pursue:

(1a) Build a brand new authn flow and invoke it from our MFA script near 
the top.  Advantage: probably no more need to mess with impl classes.

(1b) Similar to above, but just call a bean direct from the script 
instead of authoring a complete authn flow.

(2) Hook in the same way/place as before, and create the SessionContext 
and IdPSession as before.

(3) ExtractActiveAuthenticationResults can be overridden by property 
idp.session.activeResultExtraction, but this only works if a 
SessionContext with an IdPSession already exists.

(4) Create a replacement SessionManager that will build a SessionContext 
with IdPSession based on the cookie.

The general thought is to somehow generate the cookie-based 
SessionContext/IdPSession prior to the standard authn flow checking for 
previous results, so that normal SSO processing happens.

Any advice?  Thanks!

-- 
%%  Christopher A. Bongaarts   %%  cab at umn.edu          %%
%%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
%%  University of Minnesota    %%  +1 (612) 625-1809    %%



More information about the dev mailing list