I want to understand if its possible to setup onlogin for SSO for hashicorp vault. I couldnot see that in oidc auth methods but i think there can be some way to enable this. Has someone did something like this before and guide me if its possible.
OIDC is a standard method for authentication and as such should be supported independently of the IdP you use.
That being said, there are certain details about each IdP setup that can cause you some headache but in general if you understand the concepts behind OIDC, you should be able to work it out.
As you mentioned, Onelogin is not on the list of example providers but I’d assume this tutorial is a good starting point.
If you have any issues while following along, just post the configuration steps and the errors you’re facing here.
Thanks much for your response. I was able to configure one login with SSO and it works via UI. For CLI, currently its giving me issues. Infrawise, we are running vault in ECS Task and ALB routes the request from 443 to 8200. When I am trying to run below command:
vault login -method=oidc role="reader" listenaddress="0.0.0.0" callbackhost="vault.example.com" callbackmethod="https" callbackport="443" port="8200"
Complete the login via your OIDC provider. Launching browser to:
Waiting for OIDC authentication to complete...
Error authenticating: Unable to authorize role "reader" with redirect_uri "http://localhost:8250/oidc/callback". Check Vault logs for more information.
In this case it tries default values which is not correct in our case as url is vault.example.com and port is 443
Ah, no - that is a misunderstanding. When you execute vault login -method=oidc the URL involved in the OIDC redirect is not the URL to your Vault server.
Rather the URL is almost alwayshttp://localhost:8250/oidc/callback and the thing listening at this URL is the local Vault CLI command itself!
You do need to configure your Vault server to allow this URL as a redirect URL, which I think is what is missing here.
You will also need to configure Onelogin to allow this as a redirect URL for Vault.
The full flow is this:
User runs vault login -method=oidc
Vault CLI calls Vault server, asking it for an URL a browser can use to start the authentication
Vault CLI launches local browser using the URL fetched in the previous step. Meanwhile Vault CLI starts listening on http://localhost:8250…
Browser interacts with identity provider as needed. If successful, identity provider redirects the browser to http://localhost:8250/oidc/callback - where the original Vault CLI is listening - which is how the successful authentication makes it back to the Vault CLI
Vault CLI sends a one-time code received via the browser redirect, to the Vault server, where it is used to finalise the login and return a Vault session token
I am trying to configure 2 roles for vault one is writer and another is admin… i am able to create them on vault but problem is that when writer is trying to use admin role, they are able to login using that role. I think i am not creating the correct mappings… This is my admin role:
That’s because you don’t have any bound_claims which means anybody with any set of claims that logs in via this provider will be granted that role, so long as they specify it.
If you want to enforce different rights for each IdP group, there are essentially 2 ways:
For each role, you can specify Bound Claims so only people with those claims can assume the role (bear in mind, the users still have to specify the role when logging in - if you don’t want that, see the next option) OR
Everybody gets a default role, say “reader”, and based on their groups claim, you grant them extra policies via External groups and group aliases, “admin” to people in the “Admins” group and “writer” for people in the “Writers” group for instance. In this case, there is only one default role without any bound_claims.
I’d like to ask, why do you think you need multiple Vault OIDC auth method roles at all?
IMO, almost everyone using the Vault OIDC auth method should be defining one role only, and setting it as the default role, so that people logging in do not need to type a role name at all.
I have seen people in these discussion forums trying to do what you are doing fairly frequently - I assume you are being led astray, because you associate the “role” in the Vault OIDC auth method, with the “role” as in Role Based Access Control … however, this is a false association. The word “role” is simply a very generic English word, and in the context of Vault, “role” is used to mean “configuration profile”. It does not mean “group” or anything similar in an access control sense.