We have WS-Fed protected non-public systems which are not accessible through the browser and we need to authenticate with them through the backend.
It is very easy to obtain a SAML token through the client’s WS-Fed endpoint when you are making the call through the browser and already are authenticated with Auth0 session cookies.
What options do we have on the backend?
We do have access to the user’s access token.
Can we somehow exchange access token for a SAML token, or call the Auth0 SP WS-Fed endpoint with an access token without a browser session?
We have tried all sorts of combinations with custom databases and social connect app contraptions and mock WS-Fed IdPs but these all boil down to impersonation and due to audit we need a non-impersonated SAML token, one which has been issued by Auth0 without a 2nd leg IdP by using the access token as proof of identity (authentication).
To my knowledge we only support the passive requestor profile when it comes to the Auth0 service being a WS-Federation identity provider so like you said this would imply the presence of a browser (user-agent). Due to this I’m afraid what you require does not seem to be supported.
I’m afraid that RFC is not currently supported and I may be missing something, but that RFC would be relevant for an OAuth 2.0 outcome (as in, getting OAuth 2.0 access tokens) while the backend you mention is expecting a WS-Federation outcome so unsure if it would be a full solution even if the RFC was supported.
I am hoping with something like the JWT token profile I’ll be to re-authenticate and call the passive Ws-Federation endpoint by setting Authorization: Bearer with the access token that I posses to obtain the SAML without needing to do interactive authentication through HTML, because the access token itself is proof of authentication.
We can already do the same (with a hilariously hacky workarounds suggested by Auth0) through a custom database connection by passing the access token through the web form in the password field and into the custom database which when successfully verified (where’s
your token verification endpoint?) returns an authenticated session and in turn an Auth0 cookie and then we call the Ws-Federation endpoint with whr name of the custom database connection or fake Federation.
This does feel remotely like 7523 except that I’m sending the JWT as a password through a form field instead of Authorizatiot Bearer, not to speak that then I need to link accounts and all of that.
I see your point, but I think the issue is that (I guess programmatically) sending a token through a password form is what can technically cause this to be similar to the RFC in question, but where I would personally not even try to make that comparison as I the thing I would be calling similar is already being abused.
In other words, you’re abusing the passive endpoint for a WS-Federation flow and really calling it programmatically as if it was more an active endpoint. It’s been a while since I worked with WS-* family, but I think if programmatic retrieval of assertions is needed this kind of steps more in the territory of WS-Trust than WS-federation passive authentication.
Well the active endpoint (STS) would require a security token to issue a SAML for the subjects. I can envelop that base64 access token in a custom XML security token and be done with it in minutes, I’m a WS-* guy myself too. Since the subject is proven, the audience is the same, and the issuer is trusted the abuse you speak of I guess is of technical rather than security point of view? What do you mean by abuse? The screen scrapping of the callback we do to get the SAML out of the callback? Or the quasi impersonation that we must do?
This is exactly what was suggested to us by one of Auth0 enterprise consultants
The subject doesn’t change the audience doesn’t change, the issuer doesn’t change. Instead of JWT you get a SAML representation of it. Technicaly only the format of the token changes, from JSON to XML which from XML canonicalization point of view they are the same token.
You don’t have an active STS, you don’t provide JWT for SAML token exchange (see Forgerock), you don’t let us upload our own signing key for SAML.What do we do?
This is hilarious to me
This was supposed to be the simplest task in the project, and now became the topic of the month.
Yeah, your assumptions were rather accurate, my reference to abuse was mostly around using an approach a bit more creatively than what is its standard use case. As in I would consider the passive WS-Federation flow to be completed by a human interactively instead of programmatically. Although there’s always additional considerations when extending something a bit beyond its normal usage and sometimes those considerations can also be security related. From a personal opinion point of view I try to stay away fro creative solutions, but that’s also easy for me as technically I’m no longer in the business of actual software development.
I understand that all of this is frustrating and I have to confess that only when I read something you said about the lack of active endpoint which is something I already had mentioned as not available in the service did I consider the fact that was basing that on a quick documentation search. Let me check this in more detail because I know that when we act as relying party I believe we do support some active flows in ADFS connections. Let me see if there’s more to this in terms of an active authentication endpoint.
So, not so good news; there was indeed some support for what would be considered an active authentication endpoint, but I checked with our product team and at this time this would not be usable so we pretty much back to the same point where I don’t think I will be able to be very useful.
I do agree that this can be both confusing and frustrating so if you can spare the time I would do recommend for you to share some feedback about the poor experience through Auth0: Secure access for everyone. But not just anyone.. I don’t promise that by doing that we will release something usable for this scenario, but I can confirm that feedback submitted through that channel is directly reviewed by the relevant product teams and although as a consequence of my internal check they gave some awareness about this situation, unfiltered feedback directly from our user is much better.
Thank you @jmangelo. I will send a feature request. It’s not so much frustrating because the lack of the feature as much as because when a PoC was done before chosing Auth0, this crucial element was somehow underestimated.
Nonetheless we will upgrade the legacy SAML services to Oauth2 but we were hoping that we can postpone that sometimes in the future. For now we’re going to live with what we have, the workarounds.
Thank you once again.
