Thanks for your question.

How Our Single Sign-On Works

Our tooling uses a single sign-on layer.

HTTP Headers

There are three important HTTP request headers in use:

• X-AUTH-token
• X-AUTH-roles
• X-AUTH-username

The username header identifies the user making the request. The token is the SSO authentication token and the roles confusingly are not roles at all but are the user groups that the user is a member of.

Nginx Auth Proxy

In our infrastructure each API call goes through Nginx that first makes an authentication call to an identity service. The identity service is responsible for checking that the token is a valid token for this username and that it has not yet expired. It must then lookup the user's user groups and set these in the roles header as a comma separated list. The job of the identity service within our infrastructure is done by the Identity Management Service that integrates with Atlassian Confluence and Jira users via Atlassian Crowd, but this role could be performed by any other authentication service, it's a great integration point.

Snowstorm Admin

Snowstorm is responsible for storing which user groups have specific roles. Either globally, across all CodeSystems, or on specific CodeSystems or branches.

How Roles are Applied

Once a Snowstorm API request has been auth-proxied to the identity service and picked up the correct user groups the request is proxied to the Snowstorm application. The security filters in Snowstorm use the user groups to lookup which global roles the current user should have. These are listed at the bottom of the response when loading a branch, as you have shown.

Your Choices

To make API requests have the correct roles you have two options:

1. Deploy a service that plays the part of the Identity Service. This would provide a way for different users to have different roles within the authoring platform. The service could be the IMS service that we use or a small custom service that integrates with your existing LDAP or other user management service. I can provide more information on the requirements if you like this option.

2. If you are hosting your own authoring platform it is possible to implement a workaround. As long as the correct HTTP headers are set when the request gets to the Snowstorm application it will give the correct role to that request. This will not work in our environments because all API requests go via IMS and that rewrites the headers.
   You just need to get Nginx or some other web proxy to set the X-AUTH-roles header to the correct user group.

In Nginx this might look something like:

proxy_set_header X-AUTH-roles "snowstorm-admin";

I hope that helps!

Kai Kewley

from snowstorm.

Thanks @kaicode for your response. It helped us to understand the issue further.

Regarding solutions you have suggested, we have already implemented setup similar to yours.
But we want to replace Authentication mechanism (i.e., replacing SSO solution, Integrating Own LDAP, etc.) and few other services in future.

Can You share the details regarding, how to integrate any SSO solution with IMS.

Thank You,
Someshwar M.

from snowstorm.