<div dir="ltr">I'm wondering if anyone has done an SSO integration with Capriza Zapps, with Shibboleth both at the SP and IdP.  I've been working at it, and I've hammered it into place by spinning up a parallel IdP.  I'm hoping I've been missing something.<div><br></div><div>Some background.  "Capriza" is used to scrape legacy web applications and make them available in a mobile app with a clunky, but mobile, interface.  The solution is made up of  a mobile app, WorkSimple; a cloud-based "API" server; and an on-prem server that hosts headless Firefox browsers (effectively, the Zapps).<br><div><br></div><div>SSO begins in the WorkSimple app, which triggers a captive browser utilizing the built-in system browser (in iOS, Safari) to create a session with the cloud-based API server.  The API server initiates an SP-initiated SSO login to the IdP.  After login to the API server, the user is "logged in" to the WorkSimple app.  And that's where things start to fall apart.</div></div><div><br></div><div>From WorkSimple, the user accesses a Zapp, which is run from one of the headless Firefox browsers.  It passes the IdP session cookies from the WorkSimple app to the Zapp.  That way, when the Shibboleth SP protecting the Zapp triggers an authentication request, the headless Firefox can pass the user's session to the IdP.  If the Zapp is unable to sign-in using the user's session, the Zapp develop can also scrape the interaction with the IdP and prompt the user to sign in again.  (Where, by default, it stores the user's username and password.)</div><div><br></div><div>And this is where the fun lies.</div><div><br></div><div>1. In order to make this work, I have to turn off IdP session IP consistency.  AFAICT, this is an IdP-wide setting.  In order to avoid this, I cranked up a new Shibboleth IdP, turned off IP consistency checking, and route traffic from the headless browser host to that IdP via the BigIP.  Is there some clever way that I'm overlooking to turn off IP address consistency checking by SP entityID or client IP address?</div><div><br></div><div>2. LocalStorage.  The captive system browser understands LocalStorage, but WorkSimple doesn't forward LocalStorage to the headless browsers.  Only cookies.  However, because the browser doing the authentication can handle LocalStorage, it doesn't get cookies.  I can turn off LocalStorage in the parallel IdP... But the browser has no distinctive user-agent or other headers that distinguish it.  So, routing login requests to the Capriza-only IdP is tricky.  At present, I'm looking at routing traffic either by setting up completely parallel SP applications and making the IdP completely separate (i.e., new providerId) or by decoding the AuthnRequest in the URL and switching based on it.  Both ugly.   I assume there's no way to switch this based on SP entityID? </div><div><br></div><div>I'd go for option 3, "Dump this crap," but I'm told from well above my pay grade that that won't happen, that this was a top-down decision.  So, my choices are to play along and implement and maintain the relevant pieces of nonsense I listed above, or let the Zapps scrape the login page, allow credentials to pass through them, and allow apps that are dependent on not only the SAML config of the IdP, but also the current flow.</div><div><br></div><div>And that leaves me wondering if anyone else has dealt with this application and found a better way.  Maybe I just haven't been asking Capriza the right questions or getting them to do the right things.</div><div><br></div><div>Greg</div></div>