wishlist: Single Sign on for Evergreen Staff Client
Bug #2043040 reported by
Blake GH
This bug affects 20 people
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Evergreen |
Confirmed
|
Wishlist
|
Unassigned | ||
Bug Description
A follow-up to
https:/
We'd like to see this functionality applied to the staff client. Some questions come to mind:
Would anyone be opposed to using the same library settings? Or do you think we need a separate set of library settings to govern this feature on the staff-side?
The staff client isn't using Apache as much as the OPAC is, therefore it would seem that this patch would need to include SSO bits in the perl service(s)?
Maybe this is more complicated than it looks on the surface?
| tags: | added: wish |
| tags: |
added: authentication wishlist removed: wish |
| Changed in evergreen: | |
| status: | New → Confirmed |
| importance: | Undecided → Wishlist |
Revision history for this message
| Mike Rylander (mrylander) wrote | #1 |
To post a comment you must log in.
Some thoughts/opinions to your questions:
* Same settings? No, but...
The library settings should be /able/ to be separate, though falling back to the opac ones would not be unreasonable. In particular, it will be important to use different a IdP or different user match points for staff-side purposes.
* Do SSO at the OpenSRF level? No, that way madness lies.
It will probably end up looking like a mod_perl shim that does more or less what the OPAC side does, creating a session based on Shib and returning the auth token, and an angular service that knows how to find out (pre-login) if it should do that dance and how to do it.
* Is this actually complicated? Yes, it is extremely complicated. Both the technology itself, and more importantly, correctly implementing it.
SSO is there to make the user's life easier, but security is Hard(tm). For the user to see it as "easy" the burden has to shift to the developer and the administrator.