Users added by SSO identity providers require AdminFullAccess privilege to login to the application

[0x00-0x00]

Describe the bug Users added and validated through SSO (Identity Provider - OpenID Connect) requires the privilege of AdminFullAccess to be able to login into Vectr.

To Reproduce Steps to reproduce the behavior:

1. Configure an identity provider;

2. Add at least one user to be authenticated by using the above mentioned provider;
3. Create a group (e.g: SSO_Access) with all policies except AdminFullAccess and add above mentioned user to it;

4. Try to login with this user, it will lead to this page, instead of home page.

5. Now go back to the local administrator account, add the AdminFullAccess policy to the group;

6. Logout and try to login with the SSO user, it will login to Vectr.

Expected behavior I think it is expected that SSO users might not need administrator privileges over the Vectr instance. In current state it seems to be a requirement.

Additional Context Vectr version: 8.4.3 (updated 04/08/2022) This was affecting me since 8.3.x and I thought 8.4.3 version would solve the issue, but unfortunately it does not. So I thought in posting this here so the team can maybe solve this, as this impacts severely in the usability of the identity provider feature.

[SRAPSpencer]

I wasn't able to replicate this. Two things to check,

Did you add users to "Basic Access"? This is required for all users regardless of what groups or other permissions you have.

Also, are users being "Approved" being added to a group? If you add them to the group before approving them that might have unintended behavior.

[0x00-0x00]

Sorry taking too much time to answer this, I was in a middle of something.

But regarding the problem, yes, they do have BasicAccess permission and, of course, they are approved.

I have noted that your SSO connection is SAML2 and not OpenID connect, so maybe that's why your environment works and mine dont?

Do you guys at SRA have an instance with OpenID connect SSO properly configured?

[SRAPSpencer]

Ah, this was an OIDC and not SAML2 connection? I'll attempt to replicate using that.

[0x00-0x00]

Yes! It is described in the first image but I did not write that down in the actual step by step, sorry about that.

[SRAPSpencer]

Still unable to replicate with OIDC selected into a Dev AzureAD environment. Few potential issues that might come to mind.

Which IDp are you using? Do you have any potential username collisions between local and SSO accounts? Do you see anything in the container logs that show error? (401 Unauthorized is normal)

[doodleincode]

Adding to what @SRAPSpencer said, can you also check the browser dev tools to see which request(s) are failing?

1. If you're logged in, log out
2. Open up the browser dev tools, and then click the network tab
3. Make sure to enable log preservation
4. Clear any existing network activity
5. Sign in with SSO
6. Look for requests with a 403 status

[0x00-0x00]

Hello all,

1) Which IDp are you using? Auth0 with Google integration (OIDC)

2) Do you have any potential username collisions between local and SSO accounts? No, there isnt.

3) Do you see anything in the container logs that show error? Yes. It starts to 403 out when queries the GoldStandard database.

Client side

Beginning of the login flow, it requests to external IdP site and it seems to be working, looking solely to status codes

Then at the point it queries for the system internal GoldStandard database, it gives out 403

Server side

It is possible to identify the three 403 requests in both screenshots. All previous requests are 302, 200 or 401 (but as Paul said, 4 01 is normal) which seems to be the normal flow until that first 403 pops up.

Any suggestions?

Edit: I'd like to add that BasicAccess default policies does include GoldStandardReadAccess and I haven't changed that. I tried also adding FullAccess by adding it to SSO_Access group (that I have created) and it hasn't worked as well. My guess would be that it is denying access before even validating policies for some reason...

Edit 2: Also to reinforce the idea that IdP is working properly is the fact that by adding AdminFullAccess to the SSO user it is possible to login to vectr without problems. So, if IdP was the culprit it is strange that there is a configuration setting in vectr can remediate the issue, if IdP wasn't working properly it wouldn't login to the application the user being an administrator or not

[SRAPSpencer]

I have to admit this is a strange problem. Go ahead and shoot us an email to vectrops@sra.io so we can discuss further.

[0x00-0x00]

Sure, i will be sending it right now

[0x00-0x00]

I have done a clean reinstall to the latest version of Vectr and SSO seems to be working. I wasnt able to determine what exactly caused the issue in the previous instance.

[oscarintherocks]

Hi, I'd like to reopen this issue, I had exactly the same issue, but the problem is not only with SSO accounts, but with local accounts I have the same 403 error accesing database. The users have the proper permissions to access.

In my case, and maybe @0x00-0x00 too. I've migrated mongodb data from the testing server to the production one (standard procedure dumping mongodb in origin server and copying all the files into ./user/mongo before doing the docker-compose up). After the migration, only admin users can login, any other user get 403 in:

https://server/sra-purpletools-rest/phases/query?databaseName=GoldStandard (POST) https://server/sra-purpletools-rest/databases/checkversion/?databaseName=GoldStandard (GET) https://server/sra-purpletools-rest/databases (GET)

Maybe it's related to permissions with mongo or GoldStandard DB after migration or after modifying secrets in .env file?

Thanks,

[doodleincode]

@oscarintherocks When moving to prod, which values in the .env file changed? Did APP_NAME change?

[oscarintherocks]

@doodleincode yes, APP_NAME was changed, also HOSTNAME (of course) and all the passwords/keys (Mongo, Vectr Data Key, JWS/JWE). All the other values remain the same.

I've tried to modify APP_NAME with the original one, and after docker-compose down & up, now the permissions are working, but SSO has been broken. If I try to configure again SSO I have this new error:

2022-11-17 11:29:10,472 INFO [org.casbin.jcasbin] - Model:
2022-11-17 11:29:10,472 INFO [org.casbin.jcasbin] - p.p: id, domain, rules, eft
2022-11-17 11:29:10,472 INFO [org.casbin.jcasbin] - r.r: domain, subject, resource, context, action
2022-11-17 11:29:10,472 INFO [org.casbin.jcasbin] - e.e: some(where (p_eft == allow)) && !some(where (p_eft == deny))
2022-11-17 11:29:10,472 INFO [org.casbin.jcasbin] - m.m: domainFilter(r_domain, p_domain) && policyMatcher(r_subject, r_resource, r_context, r_action, p_rules, p_eft)
2022-11-17 11:29:10,509 INFO [org.casbin.jcasbin] - Policy:
2022-11-17 11:29:10,509 INFO [org.casbin.jcasbin] - p: id, domain, rules, eft: [[8******-f86e-40c2-ace8-*********f, *, [{"resourceType":"ANY";"resources":["*"];"subject":{};"context":{};"actions":["*"]}], allow]]
2022-11-17 11:29:10,511 INFO [org.casbin.jcasbin] - Request: [auth, { name: subject, id: 8******-f291-47d5-9f7e-********3, attributes: { USERNAME: admin, GROUPS: [Admins], DATABASES: [/auth/api/v1/identity_providers],  } }, { name: resource, value: /auth/api/v1/identity_providers, attributes: { VALUE: /auth/api/v1/identity_providers,  } }, { name: context, id: null, attributes: { AUTHN_METHOD: JWT, IP: x.x.x.x, HTTP_REQUEST_METHOD: POST, PATH: /auth/api/v1/identity_providers, ORIGIN: vectr poc,  } }, path:*] ---> true
2022-11-17 11:29:10,511 INFO [org.casbin.jcasbin] - Hit Policy: []
2022-11-17 11:29:11,686 ERROR [org.springframework.boot.web.servlet.support.ErrorPageFilter] - Forwarding to error page from request [/api/v1/identity_providers] due to exception [Password cannot be null or empty]
java.lang.IllegalArgumentException: Password cannot be null or empty

[doodleincode]

Currently, there is a known issue when changing the APP_NAME. The usage of the APP_NAME value will be deprecated in a future release. For now, use the previous value.

With SSO, looks like it's related to the change in the VECTR_DATA_KEY value. This value is used for general purpose encryption/decryption, including global secrets management which is used for SSO related storage. Try changing it back to the original value. We are aware of issues related to key management and rotation and are exploring options.

[oscarintherocks]

Thanks @doodleincode ok for APP_NAME.

For VECTR_DATA_KEY, I've tested it with the original value, but unfortunately trying to add a new SAML2 IdP in SSO fails with the same error: 2022-11-18 11:17:45,527 ERROR [org.springframework.boot.web.servlet.support.ErrorPageFilter] - Forwarding to error page from request [/api/v1/identity_providers] due to exception [Password cannot be null or empty] java.lang.IllegalArgumentException: Password cannot be null or empty

[0x00-0x00]

@oscarintherocks yes, i have changed APP_NAME and VECTR_DATA_KEY as well.

Changing back APP_NAME partially solved my problem at the time, at least for local users. But SSO was still broken even when I changed both back to their original values.

My solution was to export the data and import it to a clean install, and SSO worked. As soon I created new groups/policies to restrict READ or WRITE access from certain users into specific databases (no default databases were restricted, just to clarify), SSO broke again. My VECTR_DATA_KEY and APP_NAME were default. Eventually, I discovered that the only way to use SSO was to import my data to a clean install and not change anything related to the group or policies within VECTR.

All vectr users can see all databases and their data, unfortunately. But at least SSO works now.

[oscarintherocks]

Thanks @0x00-0x00, I decided to start from scratch instead of migrating the data from previous instance to avoid this kind of problem, in the meanwhile I tried to migrate only my assessments DB without all the other DB data, but it fails because dependencies with other DB's, and I need to create some different permissions, so, your method is not suitable for my use case.

Starting again from scratch (docker-compose down, docker rm, docker volume rm & docker prune) finish with the same SSO error:

2022-11-21 08:00:18,345 DEBUG [org.springframework.data.mongodb.repository.query.MongoQueryCreator] - Created query Query: { "displayName" : "xxx"}, Fields: {}, Sort: {}
2022-11-21 08:00:18,346 DEBUG [org.springframework.data.mongodb.core.MongoTemplate] - find using query: { "displayName" : "xxx"} fields: Document{{}} for class: class com.sra.auth.model.provider.IdentityProvider in collection: identityProvider
2022-11-21 08:00:19,936 DEBUG [org.springframework.web.servlet.DispatcherServlet] - Failed to complete request: java.lang.IllegalArgumentException: Password cannot be null or empty
2022-11-21 08:00:19,937 DEBUG [org.springframework.security.web.context.HttpSessionSecurityContextRepository] - Did not store anonymous SecurityContext
2022-11-21 08:00:19,937 DEBUG [org.springframework.security.web.context.SecurityContextPersistenceFilter] - Cleared SecurityContextHolder to complete request
2022-11-21 08:00:19,938 ERROR [org.springframework.boot.web.servlet.support.ErrorPageFilter] - Forwarding to error page from request [/api/v1/identity_providers] due to exception [Password cannot be null or empty]
java.lang.IllegalArgumentException: Password cannot be null or empty
        at com.sra.security.crypto.KDFArgon2.deriveKey(KDFArgon2.java:30) ~[sra-auth-common-3.8.3.jar:?]
        at com.sra.auth.common.service.GlobalCryptoService.init(GlobalCryptoService.java:56) ~[sra-auth-common-3.8.3.jar:?]
        at com.sra.auth.common.service.GlobalCryptoService.encrypt(GlobalCryptoService.java:29) ~[sra-auth-common-3.8.3.jar:?]
        at com.sra.auth.web.api.v1.resources.IdentityProviderResource.addProvider(IdentityProviderResource.java:179) ~[classes/:?]

It's weird, first time I was able to connect SSO without any problem, but this time I always receive same "password null/empty" error.

Do you have any idea where this password error comes from?

Thanks,

[oscarintherocks]

I've achieved to fix the problem and it's related to APP_NAME again... I was looking to this related issue: #159 and tried to configure again the default APP_NAME=VECTR. After docker-compose up again, SSO was working again. So it seems a weird error with APP_NAME despite it points to VECTR_DATA_KEY missing, when this key is correctly configured.

Thanks everyone for the tips that help me to find the fix :)