Hi,
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.
Hi Macmiranda
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...
It opens browser
https://vault.example.com/oidc/callback?code=something&state=st_something
but browser returns output like this:
{“errors”:}
When I inspect it says GET request and 404.
I guess request is reaching from one login to vault but vault is not returning response properly for CLI. Do you have any idea?
I have configured just OIDC key secret and domain did nothing on oidc_response_mode and oidc_response_type.
You have appended a bunch of extra unneeded and/or incorrect parameters to this command.
You should run only:
vault login -method=oidc role="reader"
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 always http://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.
Example config:
vault write auth/oidc/role/reader \
...
allowed_redirect_uris=...,http://localhost:8250/oidc/callback
You will also need to configure Onelogin to allow this as a redirect URL for Vault.
The full flow is this:
vault login -method=oidc
http://localhost:8250…http://localhost:8250/oidc/callback - where the original Vault CLI is listening - which is how the successful authentication makes it back to the Vault CLIHey Max, Thanks much for looking into this! I was able to fix the issue by changing redirect uri as suggested by you. Thanks Again.
Hi Again @maxb @macmiranda
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:
Key Value
allowed_redirect_uris ["https://vault.example.com/ui/vault/auth/oidc/oidc/callback","http://localhost:8250/oidc/callback"]
bound_audiences ["ONELOGIN_CLIENT_ID"]
bound_claims null
bound_claims_type string
bound_subject
claim_mappings null
clock_skew_leeway 0
expiration_leeway 0
groups_claim groups
max_age 0
not_before_leeway 0
oidc_scopes ["groups"]
role_type oidc
token_bound_cidrs []
token_explicit_max_ttl 0
token_max_ttl 0
token_no_default_policy false
token_num_uses 0
token_period 0
token_policies ["vault-admin"]
token_ttl 0
token_type default
user_claim email
verbose_oidc_logging false
am i missing something? because vault-writer users are also able to login using this 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.