[MGNLSSO-96] Non-interactive SSO access to REST endpoints Created: 15/Feb/22 Updated: 12/Apr/23 Resolved: 07/Jun/22 |
|
| Status: | Closed |
| Project: | Single Sign On |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 3.0.0 |
| Type: | Task | Priority: | Major |
| Reporter: | Christopher Zimmermann | Assignee: | Nguyen Phung Chi |
| Resolution: | Done | Votes: | 1 |
| Labels: | None | ||
| Σ Remaining Estimate: | Not Specified | Remaining Estimate: | Not Specified |
| Σ Time Spent: | 25d 7.5h | Time Spent: | 25d 7.5h |
| Σ Original Estimate: | Not Specified | Original Estimate: | Not Specified |
| Issue Links: |
|
||||||||||||||||||||||||||||||
| Sub-Tasks: |
|
||||||||||||||||||||||||||||||
| Template: |
|
||||||||||||||||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||||||||||||||||
| Task DoR: |
Empty
|
||||||||||||||||||||||||||||||
| Release notes required: |
Yes
|
||||||||||||||||||||||||||||||
| Documentation update required: |
Yes
|
||||||||||||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||||||||||||
| Epic Link: | SSO login for technical users | ||||||||||||||||||||||||||||||
| Sprint: | AdminX 9, AdminX 10, AdminX 11 | ||||||||||||||||||||||||||||||
| Story Points: | 8 | ||||||||||||||||||||||||||||||
| Team: | |||||||||||||||||||||||||||||||
| Description |
|
Investigate allowing a 3rd party system (like a node or java server) to make an authenticated REST request to Magnolia based on user/credentials managed in an IdP. See if we can get it to work, and document how it works. Key requirement: SSO for REST Endpoints. Authenticated requests to Magnolia endpoints based on user in IdP / SSO. It should be just one "technical user" that is in their IdP system. (This user would be used to hit the Magnolia endpoints.) Security dept. at a customer has general rule that all users and auth info should be in their one IdP. Makes sense. Key problem: Getting a redirection to SSO login screen when trying to hit the endpoint. (Basically the same as when any unauthenticated person tries to login, they get redirected to SSO login screen.) They just want to be able to supply token in header in the request to the REST endpoint. Using Basic Auth now. Works but security team are not satisfied. Need something more secure. "Technical User" in their Idp.. (uses Groups in Magnolia)
Basic wished Flow: (roughly described, details might be incorrect!)
More information and context:
|
| Comments |
| Comment by Nguyen Phung Chi [ 03/Mar/22 ] |
|
Hi czimmermann, mgeljic For the scope of the ticket, I think we're talking about SSO module for On-premises only. I have a look on pac4j documentation and found something:
Compare with our current implementation, I believe that we only implemented the Indirect clients flow in the SSO module. The Web services authentication (stateless/direct client) from Pac4j described here (https://www.pac4j.org/docs/authentication-flows.html#2-web-services-authentication-statelessdirect-client) are similar and seems to match with Basic wished flow (ticket description) - mgeljic can you please have a look and tell me your idea? Thanks I also found the guide to implement direct clients flow with OpenID Connect (Oidc) https://www.pac4j.org/docs/clients/openid-connect.html#b-direct-clients Thank you, cc mrajkovic , efochr we can see above is the initial discovery for this investigation ticket, not sure we need to deep dive more into it or not. Let's discuss in a grooming or separate meeting for what we plan to do about SSO topics. Alright? |
| Comment by Matt Rajkovic [ 03/Mar/22 ] |
|
Hey nguyen.phung , thanks for doing such a careful discovery! Agree, we can discuss this in a grooming / today's planning (if there's time). We will also need a dedicated meeting to the SSO topic, to implement this in a broader context. Let me set it up! |
| Comment by Mikaël Geljić [ 03/Mar/22 ] |
|
Good discovery indeed, on the SaaS feature branch, we did implement direct-authentication flows & support for configuring multiple clients in pac4j, in fact two of them:
You can see more about that in the README on the SaaS feature branch, as well as in MGNLSSO-79 and PR #53. We sketched this ticket w/ Topher with the assumption that we can first reuse this work, with SSO 1.2-cloud-SNAPSHOT (should be 3.0-SNAPSHOT after branch reconciliation / |
| Comment by Matt Rajkovic [ 14/Mar/22 ] |
|
We continue discovery on this ticket together with mgeljic and nguyen.phung |
| Comment by Nguyen Phung Chi [ 14/Apr/22 ] |
Further discovery:I've validated the setup DX Core and SSO (cloud-6.2 feature branch), technically, what I've tried:
curl -v -X POST -H "Content-type:application/x-www-form-urlencoded" "https://id-preview.magnolia-cloud.com/oauth2/default/v1/token" -d "client_id={client_id}&client_secret={client_secret}&grant_type=client_credentials&scope=e2eTestScope"
{"active":true,"scope":"e2eTestScope","exp":1649840869,"iat":1649837269,"sub":"0oa1imrwonnyHpIvI0x7","aud":"api://default","iss":"https://id-preview.magnolia-cloud.com/oauth2/default","jti":"AT.7hF5qo7CVlbkgz8ZZTSfnF0C_xxMTvEfqHkWcaOogvk","token_type":"Bearer","client_id":"0oa1imrwonnyHpIvI0x7"}
curl -X GET 'http://localhost:8080/container/.rest/delivery/demo-content/travel/about' -H "Authorization: Bearer {access_token}"
More details and discussion here: https://magnolia-cms.slack.com/archives/C033G1YA0AD/p1649837912737319
So, we should have a further discussion to choose the solution (mostly with mgeljic) cc mrajkovic , czimmermann Thanks |