SNOMED CT Refset Management & Translation Tooling

Space shortcuts

Page tree

Overview

Documentation on authentication and authorization

Authentication

In the standard "development" build of the tool, default user/password security is used.  The allowed user and roles are indicated in the config.properties file and these "fake" users can log in with the same username and password.  For example,

security.timeout=7200000
security.handler=DEFAULT
security.handler.DEFAULT.class=org.ihtsdo.otf.refset.jpa.services.handlers.DefaultSecurityServiceHandler
security.handler.DEFAULT.users.admin=admin,admin1
security.handler.DEFAULT.users.user=user1,author1,reviewer1,author2,reviewer2,author3,reviewer3,admin2,admin3
security.handler.DEFAULT.users.viewer=guest,guest1,guest2,guest3

Here, the default security service defines a number of viewer, user, and admin application role users.  To log in as, say "admin1", the same username and password woudl be used.

IMS Authentication

In the IHTSDO deployment of the tool uses "IMS" security (backed by Atlassian Crowd).  Users are allowed to access the application if they have either "refset-user" or "refset-administator" roles in crowd.  Without one of these roles, a user is considered a "viewer" and will have access to the "Directory" tab and functionality.

Upon attempt to login to the Refset Management & Translation Tool, a check is made against IMS to determine if the user is logged in.  If so, the login controller requests an authToken from the server which is used to validate future service-layer calls for that user. 

If a user is granted new roles, they should log out and re-log in to the application

Authorization

When a user authenticates (e.g. via the security service "authenticate" call), an authToken is provided

All API calls in the system take an authToken parameter as an "Authorization" header param.  

The system checks this token against a list of currently validated (and not timed-out) tokens and provides the REST API call with information about the user and their application role.  With that information the user's project role can also be checked and the individual authorization level for that call can be validated.  

Thus a logged-in (authenticated) user can still be rejected for not having privileges to access a certain call.  In particular this applies to things like write-based calls against projects on which the user does not have any role.  The RootServiceRest.java methods "authorizeProject" and "authorizeApp" are used as convenience methods for performing this authorization role.

 

 

 

  • n/a

 

  • No labels