[FOLIO-663] Get feedback on SSO development prerequisites Created: 12/Jun/17  Updated: 12/Nov/18  Resolved: 24/Jul/17

Status: Closed
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: New Feature Priority: P2
Reporter: Nagy István Assignee: Katalin Lovagné Szűcs
Resolution: Done Votes: 0
Labels: for-next-sprint, sprint16, sprint17, team1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Blocks
is blocked by OKAPI-355 Other ways to pass the Tenant Id Closed
Relates
relates to STCOR-44 How the IDP Homepage Should Interact ... Closed
Sprint:

 Description   

The functional requirements list of FOLIO's SSO integration is assembled, however some decisions have to be made before the actual development begins. The primary goal is to support SAML (Shibboleth IdP).

Where should development occur?
There was an initial idea of creating a separate fork of mod-login and implementing an SSO compatible login layer replacing the current user/password based authentication.

This however has some problems:

  • It is expected to support simultaneous username/password based authentication next to SSO login. Some users are not enlisted as SSO users, but still have to login to the system.
  • SSO login extends mod-login instead of an alternate implementation. When the user clicks "login via SSO", it will redirect to an IdP login page, and the successful login metadata is sent back to FOLIO to a specific endpoint. It's not a replacement.

In my opinion SSO should be a new feature of the existing mod-login module and will be merged once complete. Is it okay to do it like that?

How should UI handle SSO login?
The following visual requirements need some kind of discovery of the configured SSO settings:

  • The "login to SSO" button should only show when an SSO IdP is configured for FOLIO.
  • The login button's text should be changeable, or at least the visual name for the SSO endpoint needs to be configurable.

Questions:

  • Where should the configuration values come from? UI side configuration or something fetched from the backend when the FOLIO UI loads?
  • It seems that the login page is currently not a separate module. Is it okay to add SSO specific function to the current location? (Where is it actually?)
  • Can Qulto develop the UI additions?


 Comments   
Comment by Jakub Skoczen [ 14/Jun/17 ]

Hi Istvan,

I think this is a sound plan – we already talked about developing Shib support directly in mod-login.

In terms of the login page – yes it would be great if there was an extensibility mechanism for that in FOLIO. Mike Taylor I wonder if this is something we could use "plugins" for?

Comment by Nagy István [ 15/Jun/17 ]

Hi Jakub,

Just had time to watch yesterday's sprint review recording and seen the Stripe plugins feature mentioned. Are we talking about this? https://github.com/folio-org/stripes-core/blob/master/doc/dev-guide.md#plugins
Am I correct that if we are going with this solution you have to designate some kind of plugin area on the login page? Do we have any example demonstrating how such a plugin is implemented?

Comment by Mike Taylor [ 15/Jun/17 ]

Hi, István, good to meet you.

Yes, the plugins facility mentioned in the review call is indeed what's described at https://github.com/folio-org/stripes-core/blob/master/doc/dev-guide.md#plugins – which you will have spotted is UI-side only. So this could work for providing additional SSO-based UI elements, though of course the actual work would need to happen on the back-end.

Alternatively, we could use the Stripes facilities for only displaying UI elements if a certain back-end interface is available – see https://folio-org.atlassian.net/browse/UIU-74 for an example. Then the login page would just say "Do we have the sso-login interface at version 2.3 or better?", and if so it would display the elements.

The login page is presently wired right into stripes-core. There sort sort-of-good reasons for it being that way rather than providing this page as a module. For that reason, I think the best way forward with this is probably if you just create a separate issue for the UI side of SSO, assign it to me, and tell me in that issue exactly what you want.

Comment by VBar [ 16/Jun/17 ]

It would be highly preferable to keep mod-login-saml distinct from mod-login rather than extend it. This would be in keeping with the microservices approach. I don't see a compelling need to add more functionality to the existing mod-login, and don't agree that the use case of a user w/o SSO privs (and needing to use username/password) justifies it. Multiple login modules should be allowed to coexist within the same Folio and implement the same interfaces. That's what OKAPI-337 Closed was all about

Otherwise, going forward, any updates/fixes to the SAML logic bears the additional burden of regression testing the username/password functionality, and vice versa. Then as we support additional protocols, the dependencies multiply.

Comment by Nagy István [ 19/Jun/17 ]

Actually I don't think mod-login and mod-login-saml will have any common top level API. As far as i know, initially it requires only to have these endpoints:

  • Endpoint to start the SAML single sign-on, which redirects the browser to the IdP login page. This can be directly assigned to the "login via SSO" link. (HTTP GET)
  • Endpoint which receives the SAML login response from the IdP and proceed with the FOLIO login (SOAP HTTP POST)
  • Optional discovery endpoint which describes the current SAML configuration (REST HTTP GET, the login UI plugin can use this to decide if there's a need to show the "login with SSO" link, but it's just an idea)

So yes, I think you are right, it's better to not implement this inside the existing mod-login, but in a separate module. I wonder if Okapi will let through the SOAP calls associated without any issues. It's something we have to experiment with.

Comment by Cate Boerema (Inactive) [ 26/Jun/17 ]

Hi Nagy István. We are starting a new sprint today. It would be great if we could close this (assuming it's complete).

Comment by Nagy István [ 26/Jun/17 ]

There's still one unresolved issue with this.

The SAML authentication workflow has a callback, and we haven't decided how the tenant's ID should be handled there.
Developers had some discussion about this on Slack, Robert Sass is trying to get answers, but I think we haven't come to a conclusion yet. Last time I've checked the discussion it seemed that we can solve this by embedding tenant ID to the callback URL. This way we don't have to care about how SAML IdP manipulates HTTP headers. However Okapi cannot resolve the tenant from the URL at the moment. So even if we agree on this, that's have to be implemented. I think once this finalizes we can create the necessary tasks and close this issue.

I have an ongoing conversation about this here. You can access it as far Slack keeps the history of it.

I've said:

In my opinion, supporting the tenant ID embedded inside the callback URL would be the most straightforward thing to do. There's the IdP which acts as a black box in the middle, and we don't know what kind of magic it will do. I wouldn't use HTTP headers, because even if Shibboleth won't alter them, there will be sure an another SAML IdP or proxy by an institution which will work differently.

I guess your main issue here is that with the current username+password login there's no redirection happening, since by a successful login the generated JWT token is sent back to the UI instantly in the XHR call and the Stripes framework can switch to the main page / dashboard state without any reloading. I guess there should be a way that this whole SAML login can happen inside the FOLIO app without redirecting. Like say, embed it into an `iframe`, and the callback redirects handler in `mod-login-saml` could create the JWT token and yield some kind of JS event which triggers the status change of the Stripes application.

Detecting the transition can be as simple as checking if the `iframe` arrived at the callback URL or not. (`iframe`'s `onload` is called as many times a page reload happens) Or render a very simple HTML inside `iframe` which calls something on `window.parent` which is caught by stripes.

I can imagine this whole `iframe` thing can be realized in the stripes plugin which adds the SAML login functionality.

Robert Sass said:

can't we create another endpoint just like `//proxy` or `//discovery` for this kind of situations? For example `/_/proxy/tenants/{tenantId}/callback/myEndpoint` automatically routes request to `/myEndpoint` with `X-Okapi-Tenant` set to `tenantId`. Is this a bad idea

I've said agreeing:

That seems to be very close to the POST-to-GET gateway @mike mentioned earlier

However i think the SAML response should be still handled as a POST handler inside `mod-login-saml` because it has a long response message (it's an encrypted SOAP-like XML afaik)

Comment by Robert Sass [ 26/Jun/17 ]

There is a separate issue about this in Okapi project: OKAPI-355 Closed

Comment by Nagy István [ 26/Jun/17 ]

For the UI discussion there's now a separate issue STCOR-44 Closed .

Comment by Mike Taylor [ 26/Jun/17 ]

Thanks for separating this out!

Generated at Thu Feb 08 23:07:26 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.