| OHDSI Home | Forums | Wiki | Github |
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).
@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
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
Hi, I think I incorrectly marked the wrong branch as a release. Let me refresh the relase, and I’ll report back.
Ok, I’ve re-released the 2.2.1 hotfix. Please try to download and let me know if you don’t see the changes. Sorry about that!
I have successfully tested it this morning. The button enable/disable seems to be working as expected. 
Thanks for your help and support!
I have been trying to test more of the functionality of the application, and have been running into some other odd issues.
I was able to create the new concept set, however I wasn’t able to save any updates to it. I get a 403 response when I attempt to make the update. It looks like something still isn’t quite configured right in the security checks. Something else that could possibly be related to missing permissions is that the checkboxes for Exclude, Descendants, and Mapped were all disabled.
Ok, thank you for continuing to work through the issues!
If you created the concept set, then that means you had create permissions granted, but it’s possible that update permissions weren’t configured properly. if you are getting a 403 response from the server, that means that the request was made to the service, but the authorization check failed (ie: your user doesn’t have the permissions to update concept sets). This could be an issue with the security layer, we will need to investigate save/load operations when security is enabled.
Hello @larosee, @Chris_Knoll,
I was not on the Atlas topic the last few weeks but I saw your discussion and I also tried the new release 2.2.1.
It seems to solve some issues.
With the security on, I am now able to create new cohorts, update them and delete them.
However, I also have trouble with the Concept Sets. The creation button is enable but when I click on Save for the first time it does nothing except saving an empty concept set. Moreover, I am not able to delete it. The button ‘Delete’ is disable so does the ‘Save’ button if I close the Concept Set and try to modify it. I guess it is similar to what experienced larosee.
I checked my user mapping in the database and it seems ok for me. I think I should be able to do these operations.
I also noticed that to update a cohort, ‘put’ was used whereas ‘post’ was used to update a concept set. Modifying the ‘post’ to ‘put’ in the database allowed me to update and save correctly a concept set but I didn’t find a workaround to delete it.
Hi @erwanlc - just wanted to follow up on this note since we just released v2.3.0 of Atlas/WebAPI and in that new build there are a number of fixes/improvements to the security module that should help with the issues you noted. Can you try the new build and report any issues via GitHub?
Thanks!
Hello @anthonysena,
Security seems to work well with the release 2.3 !
I tested the creation, saving and deletion for all the tabs and I didn’t face any issue.
I was a bit confused at the beginning because I didn’t have access to the ‘Incidence Rates’, ‘Estimation’ and ‘Prediction’ tab by default but then, I saw the new ‘Atlas users’ role.
I will go through the other functionalities and report any issues on GitHub.
Thanks a lot for the work !
@erwanlc
Hello,
Hope you are doing well.
I am also trying to enable the security in Atlas. Could you please let me know the process on how we can do the Windows Authentication process step by step as I am not getting any fruitful links to enable the security.
As you mentioned the changes in settings.xml and config.js file, I did it and rebuild the WebAPI.war file and deployed, but I am not getting any prompt to enter windows credentials.
Any help will be appreciated,
Thank you.