[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: |
|
||||||||||||||||
| 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? This however has some problems:
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?
Questions:
|
| 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 |
| 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
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:
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. I have an ongoing conversation about this here. You can access it as far Slack keeps the history of it. I've said:
Robert Sass said:
I've said agreeing:
|
| Comment by Robert Sass [ 26/Jun/17 ] |
|
There is a separate issue about this in Okapi project:
|
| Comment by Nagy István [ 26/Jun/17 ] |
|
For the UI discussion there's now a separate issue
|
| Comment by Mike Taylor [ 26/Jun/17 ] |
|
Thanks for separating this out! |