Dex: Dex SAML config for SAML using ADFS

[ghost]

Hi all,

I'm hoping someone can help me out here. I'm trying to get the SAML config working for Dex. As stated in the title its SAML using ADFS. Is anyone aware of which specific data items Dex needs or what formats they should be in coming from ADFS? I'm relatively sure my config for this is good and that the issue is with the data that's being sent from ADFS. I can't find anything currently that shows a working ADFS config for this.

Dex config section

connectors: 
- type: saml
  id: adfs
  name: SAML
  config:
    ssoURL: https://federationadfs.<domain>.com/adfs/ls/idpinitiatedsignon.aspx
    ca: /etc/kube/<domain>/<domain>.saml.cer
    redirectURI: https://auth.<domain>.io/callback
    usernameAttr: name
    emailAttr: email

I get directed to the ssoURL and am met with a pretty generic error "An error occurred. Contact your administrator for more information. "

We're not seeing anything in the logs to indicate a specific login failure so it's likely accepting the credentials fine. It appears the issue is the SAML data isn't being presented to the server in the correct format. Any help of info that can be given is greatly appreciated.

[srenatus]

    redirectURI: https://auth.<domain>.io/callback

I think that should be /dex/callback?

Also, try setting

  entityIssuer: https://auth.<domain>.io/callback # or .../dex/callback

as ADFS might care; it's used here.

[ghost]

@srenatus Thanks a bunch! That got us a little bit further along in the process before having it fail out again. I think our main issue is not knowing what the config info for ADFS should look like. As in we're trying to figure out which variables to send from ADFS to meet Dex's requirements for authentication.

[srenatus]

This is IdP-specific, but I guess you could try another name ID format, one of these, configured in NameIDPolicyFormat.

[ghost]

@srenatus I think we might be getting our wires crossed a bit. I don't think formatting is the issue. We're able to change the formats from the IdP side anyway we like. We're trying to figure out what the ADFS claim rules need to be specifically as they define what information is queried and how that information should be formatted when returned. If someone has set it up before for this application, it should work consistently across all ADFS implementations

[srenatus]

I'm not sure I'm following. Recap: when logging in via SAML, Dex will send a client to the IdP's page, equipped with an AuthnRequest. That could be denied on grounds of the Name ID Format _requested by Dex_ -- the thing you can configure. If the authn request is not denied, and the IdP has authenticated the user, they are sent back to dex, with an AssertionResponse. The assertions contain some "name" field, in accordance to what was initially requested.

From your screenshot, I gathered

The SAML request contained a NameIDPolicy that was not satisfied by the issued token.

While I have no idea what "the issued token" could mean here, it does seem like a good indicator for fiddling the name id policy knob 😉

[ghost]

@srenatus I see where you're coming from. I messed with the Name ID format and worked with our ADFS Admin and ADFS and Dex are in agreement over how they want their requests formatted as we're no longer seeing errors in ADFS. But we still don't know what data Dex is looking for specifically. We're now running into

I greatly appreciate the assistance on this BTW

[srenatus]

Slowly but surely 😄

Let's check dex's logs while attempting that SAML login. Also, there's SAML dev tools for many common browsers that let you inspect that passed-around SAML blobs more nicely.

[ghost]

@srenatus Dex Logs may have led us to the smoking gun here. We're seeing the following error in the Dex Log when attempting to log in.

{"level":"error","msg":"Failed to authenticate: no attribute with name \"email\":

Looking at the response from ADFS there's definitely no attribute in the response specifically called "email". I'm working with our ADFS admin to see if he can have us return an email attribute. I'll post back again once I've verified if this is the fix or not. But ultimately this is what we were looking for "What is Dex looking for in the response from ADFS".

[srenatus]

Yay, progress 🎊

But ultimately this is what we were looking for "What is Dex looking for in the response from ADFS".

This is the tricky bit, really: it's configurable on both ends. In Dex, you've got a few SAML connector config values that are relevant:
https://github.com/dexidp/dex/blob/a1b6ba9bbad8bafbd680931a2bd5b6176df27dbb/connector/saml/saml.go#L93-L100

Depending on the flexibility of your ADFS admins, you could look at the Assertion Response and set your dex config values to something that's already included; or change the settings in your IdP to have it include what you want.

---

❓ When you get this resolved, would you mind posting a conclusion here? It would help future users to know
a) which IdP product you're using as SAML IdP there
b) what configuration on both sides has worked in the end.

[ghost]

@srenatus I finally got it working based off that last bit of info you gave me. I guess i wasn't understanding that in the config I could change the emailAttr section to expect what we were returning in our ADFS response in this case the email value was stored in an attribute named "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress". Once i changed the config to match against that value everything started working correctly.

DEX Config

connectors:
- type: saml
  id: adfs
  name: <company name>
  config:
    ssoURL: https://federationadfs.<domain_name>.com/adfs/ls/idpinitiatedsignon.aspx
    ca: /etc/kube/<domain_name>/saml.cer
    redirectURI: https://auth.<domain_name>.io/callback
    entityIssuer: https://auth.<domain_name>.io/callback
    usernameAttr: username
    emailAttr: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
    nameIDPolicyFormat: emailAddress

We're using ADFS (Microsoft Active Directory Federation Services) as our IdP.
Below are screenshots of our claim rules

[ghost]

@srenatus Thank you so much for the assistance. Hopefully with the above documentation someone else can avoid some strife in configuring ADFS to play with Dex.

[srenatus]

:tada: This is great. Thank you so much for the detailed infos. :smiley:

[andrewwebber]

@srenatus @sdollison thank you so much for posting the answer to this issue