[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:
Relates
relates to MGNLREST-71 Rest authentication with API Tokens o... Accepted
relates to MGNLSSO-132 Enhance multiple clients configuratio... Closed
relates to MGNLSSO-131 Create integration test for Direct cl... Closed
dependency
Sub-Tasks:
Key
Summary
Type
Status
Assignee
MGNLSSO-109 Implementation Technical task Completed Nguyen Phung Chi  
MGNLSSO-110 Review Technical task Closed Evzen Fochr  
MGNLSSO-111 PiQA Technical task Closed Nguyen Phung Chi  
MGNLSSO-112 Final QA Technical task Completed Thai Chi Minh  
MGNLSSO-113 Documentation Documentation Task Completed Alex Mansell  
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: AdminX

 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.
(Not product docs at this point, just internal tech notes.)

 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!)

  • 3rd party system hits db-web-sso/F5/IdP service to login and get a JWT token.
  • 3rd party system hits Magnolia enpdoint with token in header.
  • Magnolia authenticates and authorizes the request, likely invoking the IdP's token introspection endpoint; then executes endpoint with appropriate permissions.

More information and context:
https://wiki.magnolia-cms.com/display/TH2/Plan+for+SSO+API

 



 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!

efochr , mgeljic: FYI

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:

  • one for SPA access (not sure if it's actively used because delivery endpoints happen to also be public on author instances)
  • one for e2e tests and ability to bootstrap resources programmatically

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 / MGNLSSO-78) on a 6.2 instance. Essentially trying to validate an incoming token through the IdP's token-introspection endpoint.

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:

  • I made some changes in SSO module (based on feature/ssoVersion-1.2-cloud-SNAPSHOT branch) - here is the commit and new branch sso-for-rest-based-cloud-version
    • {}Basically, what I did are made the SsoSettings class to be able config using yaml
    • Unfortunately, I need to change the structure a little bit (different with mircoprofile file) and only support fixedMapping (FixedRoleAuthorizationGenerator) because the Map/List in fixedMapping and groupMappings can’t read from Yaml
  • Can login using my own Okta account with the setup DX Core 6.2 and SSO cloud with the changes above
  • Get the access token from Okta using HTTP request
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"
  • Call Okta introspect endpoint with the access token
    curl -v -X POST -H "Content-type:application/x-www-form-urlencoded" "https://id-preview.magnolia-cloud.com/oauth2/default/v1/introspect" -d "client_id={client_id}&client_secret={client_secret}&token={access_token}&token_type_hint=access_token" 

    Will have a result like this:

{"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"} 
  • Setup a simple Delivery endpoint (from this docu) and call to the endpoint with the access token, it works successfully, can view the log debug file:
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

 
In conclusion, I think this flow and setup is matched with the desired flow which described in https://jira.magnolia-cms.com/browse/MGNLSSO-96).
The key points are: * Clients have to get the access token from the SSO IdP by their own (by calling to the IdP endpoint)

  • Then, they can use the access token to interact with Magnolia Endpoint with the token in header
  • Magnolia SSO authenticate and authorize the request (invoke IdP’s token introspect endpoint to get the information from the token). then executes endpoint with appropriate permissions.

 
Regarding the work to achieve the use case (MGNLSSO-96), we can say the functionality is somehow already available in SSO 1.2-cloud-SN branch but it only support microprofile configuration which does not work on DX Core 6.2. IMO, we can have 2 proposed solutions:

  1. Reuse all the work already done in cloud version, rebase SSO cloud feature branch to master, we will have SSO 3.0 at the end. Ideally, it should support both microprofile and yaml configuration to config SSO module, so the magnolia-core also need to rebase/available in 6.3 (Customers may need to upgrade to 6.3). Ticket https://jira.magnolia-cms.com/browse/MGNLSSO-78 (The ticket does not mention the support yaml config yet)
  2. Pick the necessary functionality code from SSO cloud feature branch to master (still SSO 2.x version), the module still works with 6.2

So, we should have a further discussion to choose the solution (mostly with mgeljic)

cc mrajkovic , czimmermann 

Thanks

Generated at Mon Feb 12 10:51:05 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.