SAML authentication back-end?

[sochoa]

My team at work is wondering if this project has plans to support SAML, Github Enterprise (via OAuth), or both, anytime soon? We have a need for something like Vault.

[sethvargo]

Hi @sochoa

Thank you for opening an issue. This is not something that is currently planned, but sounds like a great idea. I have tagged as an enhancement. We would also gladly welcome a community contribution for this functionality.

[sochoa]

I'm game for contributing. Does the project have any docs on writing an authentication back-end?

[sethvargo]

Hi @sochoa

We do not have an "developer documentation", but you can follow the pattern in the existing GitHub authentication backend, for example. You might also be able to extend the existing GitHub backend to support a custom URL (and then everything else should "just work") :smile:

[armon]

@sochoa supporting GH enterprise is something we want to do, but SAML is the more questionable one as @sethvargo pointed out. I think supporting a custom OAuth endpoint in the existing provider should not be too hard! It may be worth splitting this ticket into two to clarify between the two.

[dalehamel]

@armon @sethvargo @sochoa

I think SAML would be a huge win, as it is a standardized authentication interface, rather than having to implement something specific for each provider.

For instance, I'd like to use vault with Okta. I could write an integration specific ta Okta, but that seems like a waste since Okta just supports SAML.

I'll have to read up more on how SAML works to see if it's within my depth to contribute support for it, but I think that that this should really be a core feature of vault.

[jefferai]

For future reference, mattbarid/gosaml can handle client requests; it may be a useful starting point for anyone trying to code a server library. I do think that the core functionality for managing requests (parsing, signing, etc.) probably needs to be coded outside of Vault (perhaps as enhancements to gosaml) rather than living in a backend.

[jefferai]

Another thing to mention is that Vault may be able to act as a signer for SAML applications, when given an appropriate private key, but currently there is no way for Vault to handle raw XML requests (although it can generate them). This limits the utility of a Vault SAML backend right now since there would have to be an actual SAML server to handle requests from third-parties.

[andrewstuart]

I have the rough beginnings of a SAML2 client put together, which can decrypt but not yet authenticate (xmldsig and xml-c14n are seriously painful) encrypted SAML assertions from Shibboleth. Thus far it only works for the specific settings Shibboleth was configured with (the defaults for this docker container), but those were at least pretty solid settings -- RSA-encrypted AES key for decrypting the main assertion body.

I know there are quite a few caveats in there, but IIRC mattbaird's client doesn't do much in the way of SAML2 assertions, just in generating the Authentication Request. Kinda seems like it was abandoned pretty early on, unfortunately. I know I'd have a lot of interest in getting a proper Go SAML implementation working, and I'd love it if the work I put into that library ends up going somewhere.

I'd also be glad to help with contributions on an auth backend for SAML. It seems like a fun challenge and some motivation for me to keep working on the remaining XML insanity to get signature validation working.

[radeksimko]

SAML backend is on my radar too, although from what I found so far it doesn't look as easy as I originally thought.

Even though SAML is kind of standard protocol, it only defines the core part of the user flow, typically beginning and end (those are the parts covered by most SAML Go libraries you find on the internet today). Anything in between - i.e. forms & APIs & redirects is left for IdP's creativity (unfortunately).

Hence I think that proper Vault SAML auth backend will require not only mattbaird/gosaml but also IdP specific logic, e.g.

• ADFS - https://github.com/wernerb/aws-adfs
• Ping Identity
• OneLogin
• Okta
• Shibboleth
• etc.

Some IdPs provide APIs which may make the implementation easier, but some just don't, so the library may just end up parsing form fields in HTML and sending POST requests to submit a form. :cry:

Even though most of the IdP-specific and SAML-specific logic can (and should) be outside of Vault, I think that Vault will need to recognise the differences between IdPs in configuration.

[andrewstuart]

So I'd definitely like to revisit this, as I've made some leaps integrating the separate efforts of @russellhaering (and @phoebesimon) on their saml2 library which did not support decryption but does validate signatures, and my earlier effort, which can decrypt but not validate signatures. I think we'll have a solid foundation once russellhaering/gosaml2#5 is ready for merge.

Would there be any precedent for vault opening up a browser window for the authentication piece, redirecting to a known dynamic URL (to tie it to the shell authn request), then closing the browser window? My main concern is that the SAML flows I'm aware of will likely make console authentication a royal pain, and definitely not a great user experience.

[jefferai]

@andrewstuart Probably the right thing to do would be to have a separate application that uses Vault's API (the CLI is just an API client).

[radeksimko]

@jefferai what would be such application passing to the CLI/API? SAML assertion bodies?

[jefferai]

@radeksimko I don't know? I was just answering the question posed.

[andrewstuart]

Haha so the root of the issue is that SAML is built around the browser, and is asynchronous. Though I'm only familiar with Shibboleth, I think nearly all Identity Providers (IdPs) are browser-based for the AuthN step, and the Redirect (assertion as xml encoded in a base64 query param) or form POST bindings (assertion as xml encoded in a base64 POST body) directed at the Relying Party (aka Service Provider) assertion consumer endpoint.

So to have an intermediary application, it must be a long-lived well-known application because it must have its public certificate registered with the IdP and associated with the full URL of the assertion consumer. I don't see any particular problem with this, but at that point, it's more of a sidecar application than an authentication backend, as the certs/keys would most likely need to live in the sidecar. Vault would be pretty unaware of the AuthN/Z flow in this case.

So let me propose an Auth flow, just to flesh out my own thoughts and get some feedback.

1. A Vault API client initiates AuthN via SAML.
2. The Vault API generates a signed SAML AuthN Request URL, and returns the Request to the client along with the Request ID and/or a generated secret (and perhaps explicit expiration), as the Request ID may not be confidential. The client can use this Request ID and/or generated secret to query the status of the SAML AuthN request and obtain longer-lived creds upon successful SAML AuthN.
3. The Vault API client uses the SAML AuthN request however it sees fit.
   • For the official cli, I would imagine opening the URL in the default browser.
4. Vault receives the SAML assertion at an AssertionConsumer endpoint, and validates that the IdP is trusted, assertion is valid, etc. As the client of this endpoint is possibly a browser, return a message indicating status of the SAML Auth request, and stores the success for the ID/secret it generated earlier, with expiration at some point.
5. As this is an async flow, the Vault API client either polls or holds open a connection to the Vault API (identifying the "AuthN session" via the ID and/or secret it received) and, upon successful SAML AuthN, is granted a session token.

I'm sure I've missed a few things and it could likely be improved, but I definitely wanted to get something out there to start with. :-) Let me know what you think.

[argais]

are there any plans/roadmap/timeline/etc on this?

[jefferai]

Nothing currently, sorry.

[DarioAmiri]

This is profoundly disappointing. The issue is closed, but I can't help myself from addressing the incorrect assumptions/conclusions drawn by @radeksimko.

• SAML is not "kind of a standard" it is an exhaustively documented standard that is rigorously specific about all communication between the Identity Provider (IdP) and the Service Provider (SP), which would be Vault's role in this case.

• Besides the SAML Core specification, there is also the SAML Binding specification, which is rigorous about how to use POST and Redirect bindings to pass SAML messages between the SPs and IdPs.

• Furthermore, the SAML Profile specification provides all the details necessary for browser-based SAML SSO.

• Yes, SAML does not say anything about how to create the login form on the IdP side, but this does not matter because it's past the layer of abstraction. The only thing a Vault SAML authn backend should concern itself with, is how to pass messages back and forth between the Vault and any given SAML IdP. How the IdP authenticates the user is completely irrelevant. In fact, that's actually the reason why you want to support SAML, because it allows the IdP to authenticate the user in whatever way it sees fit. I.e. showing a familiar corporate login form, using various additional factors of authentication, etc.

• Yes SAML is a difficult standard to implement and the Go libraries for SAML support are not mature. So consider implementing something like OpenID Connect (OIDC) instead. OIDC has gained a fair amount of traction as a simpler alternative to SAML.

In conclusion, I hope the Vault project will reconsider/consider implementing a SAML or OIDC authentication backend. It would simplify integration and help drive adoption, especially among identity professionals who know and trust these standards. And, at the risk of being labeled a conspiracy theorist, I really hope that the reason for not supporting these standards has nothing do with the fact that it would enable third-party or in-house IdPs to provide MFA, instead of having to buy Vault Enterprise to get this feature.

[jefferai]

@DarioAmiri the issue isn't closed...

[DarioAmiri]

@jefferai My bad. I think I got a little too fired up, I will curb my enthusiasm.

[jefferai]

@DarioAmiri I also want to point out that although @radeksimko does work at HashiCorp now, at the time of his comments he was not a HashiCorp employee, and he is not on the Vault team. They should not be considered to be HashiCorp's official position.

[jefferai]

I feel the need to clarify something:

@radeksimko is totally awesome. My previous comment is not a rebuke of his opinions, it is only meant to say that the Vault roadmap is set by the Vault team; what I was trying to get across is that while his technical input is welcomed (as is everybody's), it should not be viewed by others as a statement about the Vault roadmap.

Also, thanks for the apology -- for guidance around comms we often refer to our https://www.hashicorp.com/community-guidelines

[DarioAmiri]

@jefferai Thanks for clarifying. FWIW I have no reason to doubt @radeksimko's awesomeness. My intent was to highlight incorrect conclusions/information in the thread.

[maunzCache]

Uhm this issue is a bit confusing. It the ticket now closed, is it still open or in other words what is the current state on the issue?

[Oneiroi]

@getjack #370 is still open, the confusion came as other issues which reference this one are closed and users 'skim reading' has lead to confusion and presumption of this issue being closed.

I am unsure as to the hashicorp team's priorities on implementing this functionality, however afaict this issue is still very much open.

Note to hashicorp team: Please provide an update to indicate if this is still under consideration or on any roadmap for implementation, thank you!

[jefferai]

It's still under consideration, just not a priority. Many, many more customers are asking us for OIDC rather than SAML so that's a higher priority.

[ghost]

we are holding off implementing vault until we have SAML that will work with AzureAD with proper role assignment.

[ghost]

4 years later ? any updates on this or any support for AAD auth / office 365 ?

[DarioAmiri]

IIRC HashiCorp sells SAML, and SSO support in general, as an enterprise feature. Therefore, it is unlikely that you will see support for this in the open source version.

[jefferai]

@DarioAmiri this is not correct. We do not support SAML in any edition of Vault right now, and our SSO support (in the form of OIDC) is in OSS.

[jefferai]

@steven-cuthill-otm Many of our customers are using OIDC auth with AAD.