Is it possible to fill token field of auth form with token taken from URL like http://127.0.0.1:8200/ui/?token=472b885c-7eb0-2f32-052f-03060c402c09?
The idea is to auth user with some corporate Single Sign On service, issue new token in Vault and redirect user to webpage http://127.0.0.1:8200/ui/?token=472b885c-7eb0-2f32-052f-03060c402c09.
Unfortunately we do not use LDAP, okta or anything else Vault does.
maxsivanov
All 3 comments
This isn't something we currently support - but this could be useful if the auth form fills on init based on a parameter - with one change - if you sent a wrapped token (and changed the query param to wrapped_token) the UI could unwrap it and then fill the token field with the value and show an error if it can't unwrap it. That way we never expose the real token via the URL.
We're making some changes to the auth page that makes it a bit more user-friendly so you'd also likely have to specify that you want to log in with the token backend - that's currently the with query param - so in the end it'd look more like http://127.0.0.1:8200/ui/?with=token&wrapped_token=472b885c-7eb0-2f32-052f-03060c402c09. Users would also still have to click to login, though maybe it'd be smoother to just submit the form on successful unwrap 馃- will have to think that over.
meirish
on 25 Jun 2018
I've implemented this and have a PR up - to clarify just specifying ?wrapped_token=<token> is enough to trigger the behavior and we did end up just submitting the form on successful lookup to make any integration smoother.
meirish
on 30 Jun 2018
This will be very useful for many diff integration workflows. SSO being one.
Thanks for submitting this.
palsaurabh2005
on 2 Jul 2018
Related issues
jasonmcintosh
路
3Comments
trodemaster
路
3Comments
passwordleak
路
3Comments
tustvold
路
3Comments
gtmtech
路
3Comments
Most helpful comment
This isn't something we currently support - but this could be useful if the auth form fills on init based on a parameter - with one change - if you sent a wrapped token (and changed the query param to
wrapped_token) the UI could unwrap it and then fill the token field with the value and show an error if it can't unwrap it. That way we never expose the real token via the URL.We're making some changes to the auth page that makes it a bit more user-friendly so you'd also likely have to specify that you want to log in with the token backend - that's currently the
withquery param - so in the end it'd look more likehttp://127.0.0.1:8200/ui/?with=token&wrapped_token=472b885c-7eb0-2f32-052f-03060c402c09. Users would also still have to click to login, though maybe it'd be smoother to just submit the form on successful unwrap 馃- will have to think that over.