OHDSI Home | Forums | Wiki | Github

Atlas Creation button disable after activation of security

Hello,

I am trying to activate the user authentication on Atlas.
In my WebAPI settings.xml, I changed:

<security.enabled>true</security.enabled>

In my Atlas config.js, I changed:

config.userAuthenticationEnabled = true;

I am using only Windows authentication and I am able to connect but after giving roles to users, the ‘New Role’, ‘New Cohort’ and ‘New Concept Set’ buttons stay disabled. For testing purpose, I gave my first user every rights so it can access to every pages even the ‘Manage Permissions’ page but still can’t click on creation button.

Do you have any idea why ? Did I miss something in the configuration ?

I am using Atlas and WebAPI 2.2.0.

Thanks for your help.

Hello,

Thank you for your email regarding [OHDSI Forums] [Implementers] Atlas
Creation button disable after.

I am currently at a training and I have limited email access. I will respond
to your e-mail upon my return on Friday, November 17th.

Thanks for your patience,
Valerie.

Hi @erwanlc - it looks like you have enabled the right settings for both WebAPI and Atlas. When you connect to Atlas, do you see the “sign in” button in the top-right corner? And are you able to log in using your Windows Credentials?

If you can get past this point, it would be helpful to see a few entries from your SEC_USER and SEC_USER_ROLE tables in the WebAPI database just to verify that the roles & permissions are correctly associated to each user.

Hi @anthonysena ,

I see the sign in button and I am able to log in using my Windows credentials.

Here is my SEC_USER table:
ID, LOGIN, PASSWORD, SALT, NAME
1003, WINDOWS\USER, NULL, NULL, NULL

And my SEC_USER_ROLE table:

ROLE_ID from 1000 to 1006 correspond to ‘Source user’

Hi - thanks for sharing this info @erwanlc. It looks like everything is correct in terms of the role configuration. Have you attempted to restart WebAPI to see if that fixes the issue? Or have you attempted to sign out and sign back in to see if it picks up the roles?

Hi @anthonysena, thanks for your support.
I tried both solution without any success.
I also tried to enable the buttons by modifying the html source code from ‘disable’ to ‘enable’ but after clicking on them, I got the following message:
You do not have access to this feature.
For more information on how to get access please contact the system administrator.

Hi - this sounds like a security denial from the WebAPI. A few more questions:

  • Which version of WebAPI are you running? And on what type of web server? If you could provide the OS and web server platform (i.e. Tomcat 8.5) that would be helpful.

  • When you start up the web server, do you see the following DEBUG message anywhere?

    DEBUG org.ohdsi.webapi.WebApi.main() org.ohdsi.webapi.ShiroConfiguration - - AtlasSecurity module loaded

  • Would it be possible for you to upload & share the tomcat log files?

Hi,

  • I am using WebAPI lastest release: 2.2.0. The web server is Tomcat 8.5 on Windows Server 2016.

  • The closest message I got is:
    2017-11-21 09:05:02.023 DEBUG localhost-startStop-1 org.ohdsi.webapi.ShiroConfiguration - - AtlasSecurity module loaded

  • Tomcat logs are attached here. I changed the extension to be able to upload the file. tomcat_log.xml (221.2 KB)

Thanks @erwanlc for sharing this information. In terms of the WebAPI start up, I do not see any issues - the security module is being loaded properly and the bindings appear to be set up properly.

Can you gather some information from the client side? From Google Chrome, open the developer tools and attempt to sign in using Windows authentication. From the Atlas UI, you should see the sign in dialog change to show you a confirmation like this:

Assuming this worked, you should also see a corresponding network call to the WebAPI to perform the login:

Please note the encrypted bearer token in the header - this is the handshake between the client and server which is then used in subsequent calls to determine permissions to the individual REST endpoints. I’ve also attached a segment of the WebAPI logs that I captured during the login process and have attached it webapi_login_log_subset.xml (9.6 KB). In this log, you will notice that there are several Hibernate database queries to the SEC_ROLE_PERMISSION table to gather the permissions for my user ID.

Curious if you have the same set of behaviors in your environment or if you note any differences?

I did what you asked and on the client side, I have something similar to you except the Access-Control which I don’t have:

Regarding the webapi log, my logs are exactly the same as yours, so I assume everything is correct there.

Do you think that if I try to use another authentication (like google) it could solve the issue ?

Hi @erwanlc - it looks like the CORS filters are not being applied by WebAPI. In your settings.xml, do you have a value for the security.origin field? For testing purposes, could you try this:

<security.origin>*</security.origin> 

This wildcard setting will allow all traffic through which will help us with this test. This is not a recommended way to deploy in production - in a production environment, this value should contain the root domain hosting the client application (i.e. Atlas).

Can you try making this change in WebAPI and we can see if the security is then enabled?

Hello @anthonysena, I am using this value since the beginning at it was the one by default:

<security.origin>*</security.origin>

So no change in the behavior of the tools.

Hi @erwanlc - thanks for your patience here. Been talking with @Chris_Knoll and we have a few more items we’d like to confirm with you. First, on the database side, can you execute the following query to confirm all of the role permissions:

   select 
	u.id user_id,
	u.login,
	r.id role_id,
	r.name role_name,
	p.id permission_id,
	p.value,
	p.description
from webapi.sec_permission p
inner join webapi.sec_role_permission rp ON p.id = rp.permission_id
inner join webapi.sec_user_role ur ON ur.role_id = rp.role_id
inner join webapi.sec_role r ON ur.role_id = r.id
inner join webapi.sec_user u ON ur.user_id = u.id
where u.id = 1003
order by r.id, p.id

You may need to alter this query if you installed the WebAPI into a different schema. Could you share the results of this query? You should hopefully something similar to this:

The next item we’d like to confirm: when you click the Sign In button and choose the Windows authentication, can you confirm that your Windows Credentials are displayed in the Atlas pop-up? Please see my screen shot from earlier.

In addition, open the Google Chrome Developer Console and run the following commands via the Console:

pageModel.authApi.isAuthenticated()
pageModel.authApi.subject()
pageModel.authApi.isPermittedCreateCohort()

We are concerned that we don’t see these headers in the response:

Access-Control-Allow-Credentials:true
Access-Control-Allow-Origin:http://<your web server>
Access-Control-Expose-Headers:Bearer

These should should be set automatically by the WebAPI code that enables CORS filtering. The fact that these headers are not present could be the cause of any authentication issues.

Hello @anthonysena, thanks to you for your help.

I executed the query you sent and I have exactly the same results as you.

Regarding the Windows authentication, I confirm that I see the Atlas pop-up:

For the commands, please find the result below:

> pageModel.authApi.isAuthenticated()
<- true
> pageModel.authApi.subject()
<- "DOMAIN\USER"
> pageModel.authApi.isPermittedCreateCohort()
<- false

As expected, the cohort creation permission is set to false on my client side. When I test for the cohort reading for example, I get true.

It is weird indeed that I miss some headers response. I will investigate on my side but what bother me is that most of the access work fine, it is only for the creation/update of cohort, roles and concept set that I get a false response.

Hello @erwanlc ,

I don’t know if you have solved your issue or not, but I experienced very similar problems.

I noticed that the values found in SEC_PERMISSION were a little different for me than what @anthonysena had posted. The values for the Create Concept Set and Save new Cohort Definition had the term ‘post’ instead of ‘put’. For example, the default install populated the VALUE of conceptset:post, when it should be conceptset:put. The same was true for the Cohort creation permission.

After making this change the buttons for creation are now enabled when I am signed in.

Hey, @larosee,
Create actions should be POST verbs. You can see this for cohort definition service here: https://github.com/OHDSI/WebAPI/blob/master/src/main/java/org/ohdsi/webapi/service/CohortDefinitionService.java#L361 while save is a PUT: https://github.com/OHDSI/WebAPI/blob/master/src/main/java/org/ohdsi/webapi/service/CohortDefinitionService.java#L411

What this probably means is that the client side code is probably looking for the wrong HTTP verb for determining rights to create. I’d recommend you do not change the values in the SEC_PERMISSION table since those entries should align with what is in the actual WebAPI code, and I think what you have is enabled the button, but when you try to create a cohort definition you might get a 403: Unauthorized error because the create actually uses a POST verb.

We’ll investigate the issue from the UI side.

Oh. @Chris_Knoll, thank you for getting back so quickly. I guess I am back to the same place where this thread left off.

Let me know if there is anything that I can help with in this evaluation (that hasn’t already been provided above).

I’ve created a git tracking issue for this: https://github.com/OHDSI/Atlas/issues/528

@larosee, @erwanic,
I’ve pushed a hotfix (Atlas version 2.2.1) here: https://github.com/OHDSI/Atlas/releases/tag/v2.2.1. Can you please try to download this version of Atlas and let me know if this resolves your problem?

-Chris

@Chris_Knoll ,

Not sure if I am missing something here. I downloaded the v2.2.1 code, but it doesn’t seem to include the changes for issue 528. It still seems to be referencing permission for put instead of post. I’m not extremely familiar with github, but it looks like the last commit with that tag is Nov. 14, 2017: [https://github.com/OHDSI/Atlas/commits/v2.2.1][1]
[1]: https://github.com/OHDSI/Atlas/commits/v2.2.1

t