Authentication Issue in Authoring-ui

[Kartik-Rai]

Hi,

Hope you all are doing good and safe.
Whenever we have tried to access the user login in Authoring-ui, Service Referrer of the link returns back to the home page of auth-ui( on clicking the login button)
http://arp-snowstorm.mig.in/undefinedlogin?serviceReferer=http://arp-snowstorm.mig.in/#/home
so the question here is how the authentication works in authoring-ui with IMS, also I have added the context path for /auth in nginx config file

location /auth {
			proxy_pass https://dev-ims.mig.in/api/account;
		}

Also, how can we change the service referrer of auth-ui to the IMS authentication and revert it back to the authoring-ui screen with defined user.

Note- 1) Application link is already been setup in the Crowd for IMS authentication.
2) Edited the endpointConfig.json file as per our server details.

Kindly do the needful.

Thanks & Regards
Kartik Rai (NRC India)

[kaicode]

Hi @Kartik-Rai

This is the flow for authentication in the authoring platform:

• User loads Authoring UI
  • loads /authoring-services/ui-configuration to get the IMS URL.
    • This is configured in authoring-services application.properties e.g. uiConfiguration.endpoints.imsEndpoint = https://dev-ims.domain.org/#/
  • loads /auth/account to get username
• If any http from Authoring UI returns a 403 (Forbidden) response then the user is forwarded to IMS URL for login. The serviceReferer URL is used to forward the user back to the Authoring UI once they are logged in.

We host the IMS service under the same top level domain so that a single sign-on cookie can be assigned by that service and used in the authoring ui. For example the authoring ui could be hosted at: authoring.mydomain.com and IMS could be under login.mydomain.com. Then the IMS service should assign the cookie to the mydomain.com top level domain so the browser will include it in requests to services hosted at authoring.mydomain.com.

The IMS service communicates with the Crowd REST interface in order to authenticate the user and get a list of user groups. These details are cached for future requests.

We host IMS and Crowd on the same machine. Example identity-service application.properties configuration:

cookie.name=dev-ims-mydomain
crowd.api.url=http://localhost:8095/crowd/rest/usermanagement/1
crowd.api.auth.application-name=ihtsdo-tools
crowd.api.auth.application-password=XXXXX

Once the user has the single sign-on cookie all requests to authoring-services and Snowstorm under authoring.mydomain.com will include the security token. This token must be used by Nginx on the authoring server to authenticate each request via IMS and pick up the username and groups of the user. The Nginx configuration should look something like this: https://gist.github.com/kaicode/6c8fe22a0d49f8c72e558f4e7bb6e469

The backend services expect to receive requests from Nginx with the headers already set for X-AUTH-username, X-AUTH-roles and X-AUTH-token. The token header contains the cookie in case a service needs to make a request to another service as the original user.

I hope this helps!
Just let me know if you have further questions.

Kind regards,
Kai

[Kartik-Rai]

Hi @kaicode

Thanks for the great insight into the whole authentication process.

Still the issue of authentication at authoring-ui has not been resolved yet,
when i fixed this property "uiConfiguration.endpoints.imsEndpoint = https://dev-ims.domain.org/#/" into the application properties file, runs the Nginx server and tries to 'login' it goes to IMS page and after successfull authentication it returns to the home page of auth-ui but there is no user login forwarded back on the Authoring-UI page and these requests(auth, namespaces, projects, user-preferences ) are showing 404 and 500 response.

With this I understand the 403 response but there is no forwarding of user after successfull authentication,

If any http from Authoring UI returns a 403 (Forbidden) response then the user is forwarded to IMS URL for login. The serviceReferer URL is used to forward the user back to the Authoring UI once they are logged in.

I don't understand why this situation is happening, Kindly do the needful

[kaicode]

Hi @Kartik-Rai, I'm sorry to hear that authentication is not yet working for you.

Please check the following:

• the ims login is setting a cookie with the name like "dev-ims-mydomain"
• that the cookie is for the top level domain, e.g. ".mydomain.org". You can check this using a Chrome extension like EditThisCookie.
• that the browser is automatically including the cookie in all requests to the authoring platform APIs. For example open the chrome developer tools network tab, browse to a URL like http://mydomain.org/authoring-services/version and you should see the cooking in the request headers.

If this is not working check the IMS application configuration and that the authoring-ui and IMS are being served on a common top level domain.

If the cookie is being sent to authoring-services but the logged in user is still getting access denied check the nginx configuration and that the ngx_http_auth_request_module is included and enabled. This makes a proxy call to IMS on the way to Authoring Service to validate the cookie.

I hope that helps but if it is still not working let's have a call.

Kind regards,
Kai Kewley