Authentication and Authorization Beyond Basic and SAML (LDAP, OAUTH, Grouper)
(UXPROD-778)
|
|
| Status: | Open |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None | Parent: | Authentication and Authorization Beyond Basic and SAML (LDAP, OAUTH, Grouper) |
| Type: | New Feature | Priority: | TBD |
| Reporter: | Tod Olson | Assignee: | Tod Olson |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Potential Workaround: | Continue to rely on an absence of FOLIO permissions. |
| Epic Link: | Authentication and Authorization Beyond Basic and SAML (LDAP, OAUTH, Grouper) |
| Development Team: | None |
| PO Rank: | 0 |
| Rank: Chalmers (Impl Aut 2019): | R3 |
| Rank: Chicago (MVP Sum 2020): | R3 |
| Rank: Cornell (Full Sum 2021): | R4 |
| Rank: Duke (Full Sum 2021): | R4 |
| Rank: 5Colleges (Full Jul 2021): | R4 |
| Rank: GBV (MVP Sum 2020): | R4 |
| Rank: MO State (MVP June 2020): | R4 |
| Rank: TAMU (MVP Jan 2021): | R3 |
| Rank: U of AL (MVP Oct 2020): | R4 |
| Description |
|
Overview: Additional Information: URL: |
| Comments |
| Comment by Julian Ladisch [ 16/Sep/20 ] |
|
As a FOLIO tenant administrator I would like to disable the login of a FOLIO user that still has a valid SSO account. How to reproduce:
2. To enable SSO login for a FOLIO user put the SSO UserID into the External System ID field of the user's record. 3. To disable SSO login for a FOLIO user remove the SSO UserID from the External System ID field of the user's record. Expected: Tod Olson Can you rewrite your issue using https://folio-org.atlassian.net/wiki/display/COMMUNITY/Standard+Bug+Write-Up+Format ? Most universities in Germany are unwilling to store additional authorisation information in the Identity Provider (IdP). Therefore all service providers (SPs) that use SSO need to manage and store all authorisation information, and FOLIO as a SP need to be capable to do the authorisation. Your use case seems to be different. Can you give a complete example which fields your IdP passes on to the SP and how the SP (= FOLIO) can determine whether the user is authorised? |
| Comment by Tod Olson [ 16/Sep/20 ] |
|
(That description update was only partial, was not supposed to go out yet. There's a lot of set up before I can finish that.) Julian Ladisch In our current situation, we have exactly one attribute value that indicates a user is authorized to log into OLE: ucisMemberOf: uc:org:library:applications:ole:authorized Membership in that group is managed in our central IdM infrastructure, the rules are based information from the HR system, but the only thing release is this attribute that says "authorized for OLE." All of the complexity takes place in the IdM/IdP infrastructure. For the SP, it is a simple binary check. (Access to campus wireless, campus VPN, and many other entitlements are managed in a similar way.) The idea is that we could, optionally, configure the FOLIO SP to require a specific attribute value in order to authorize login. In this case, we would configure FOLIO to authorize login only if an attribute with the value uc:org:library:applications:ole:authorized (or the FOLIO version of that value) is present. |
| Comment by Julian Ladisch [ 21/Sep/20 ] |
|
Thanks, now I better understand. This is not a bug but a new feature. User stories ( https://folio-org.atlassian.net/wiki/display/COMMUNITY/Getting+Started+for+Product+Owners ) can be added to explain how FOLIO's SSO configuration settings UI should be extended. |