Integration with Capriza?

[Greg Haverkamp]

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.

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).

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.

>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.)

And this is where the fun lies.

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?

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?

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.

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.

Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20161117/aace7351/attachment.html>