Date: Thu, 28 Mar 2024 10:19:21 +0000 (UTC) Message-ID: <1467332015.275.1711621161131@[3.220.22.64]> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_274_1831417794.1711621161130" ------=_Part_274_1831417794.1711621161130 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Documentation on integration with the IHTSDO Identity Management Service= .
This tool has a configurable security architecture that allows for a var= iety of possible security implementations to be used. For IHTSDO depl= oyments of the tool, we make use of a handler (and login page override) tha= t interacts with the identity management service.
The security layer itself assigns auth tokens which get passed back-and-= forth between client and server. This handler verifies that the user = is indeed logged in (or redirects them to the "guest" view of the tool). &n= bsp;If logged in, an auth token from the application is requested that is g= ood until the timeout period is reached.
There are several important parts to how this works:
In the deployment config.properties file, the security handler must be s= et to an IMS handler that is properly configured. For example:
security.timeo= ut=3D7200000 security.guest.disabled=3Dfalse security.handler=3DIMS security.handler.IMS.class=3Dorg.ihtsdo.otf.refset.jpa.services.handlers.Im= sSecurityServiceHandler security.handler.IMS.url=3Dhttps://ims.ihtsdotools.org
The ImsSecurityServiceHandler is used with a IMS URL of ims.ihtsdotools.= org
In order for this all to work the system must be deployed on an ihtsdoto= ols.org server which has a local "ims-api" link that redirects properly to = IMS. For example,
# in the nginx= configuration file for refset deployment =20 location /ims-api { proxy_pass https://ims.ihtsdotools.org/api; }
This allows the application to check this URL to determine if the user i= s, in fact logged in.
The normal login controller handles a username/password form. For = IMS security, an override of the login controller (in the config/prod proje= ct) is used to customize the functionality. Instead, it first checks = whether the user is logged in by probing the /ims-api link (shown above). &= nbsp;
NOTE: this is not a normal thing to need to do - default build with user= name/password security is recommended for DEV environments.
In a local dev environment, IMS security can also be used. In this=
case, the user must set the deployment URL (which is presumed to be runnin=
g on http://localhost:8080/refset-rest) to =
instead be
The local dev environment then needs to have a configuration setup somet= hing like this (to support the localhost:8081 redirection back to localhost= :8080 and the /ims-api link)
http { include mime.types; server { listen 8081; server_name localhost; location / { proxy_pass http://127.0.0.1:8080; } =09=09# may need to be uat-ims for uat-authoring location /ims-api { proxy_pass https://ims.ihtsdotools.org/api; } } }
In order for this to work, nginx must be running on the dev machine.
Finally, to truly use IMS security in a local dev environment, the proje= ct will need to be built locally with "-Dconfig.artifactId=3Drefset-config-= prod" passed to Maven so the overridden login controller can be deployed.= p>
Alternatively, if IMS is needed simply to support pass-through of auth t= okens (e.g. for testing Snowowl terminology handler), then the default logi= n setup can be used (with normal username/password security) and as long as= the user is actually logged into IMS and the application is being run on&n= bsp;https://local.ihtsdotools.org, then the tokens shoul= d be successfully passed through to the handler.