The builds from 3/2 onwards include support for integrating Ignition as a Relying Party with a SAML 2.0 Identity Provider. You’ll notice the new type is available from the Gateway Config Web Interface => Identity Providers (under the Security category) => Create New Identity Provider.
Those of you familiar with configuring SAML entities should find the configuration interface self-explanatory. It provides the capability to export Ignition’s SP metadata, import IdP metadata, and manually tweak configuration options common to most SAML SPs.
Note that the initial implementation currently supports verifying Response and Assertion signatures and supports the HTTP Redirect and HTTP POST bindings for the SSO request / handling the response at the ACS. The initial implementation does not support the following:
Other bindings such as HTTP Artifact, SOAP, or PAOS
SP Signature Generation (for example: signing the AuthnRequest)
Single Logout (SLO)
Decryption of IdP Responses and Assertions
IdP-initiated SSO
As demand for the above capabilities increases, we will consider prioritizing them assuming we have solid use cases to go along with the demand.
More information will be added to the main 8.0 docs in the near future.
One thing to note: in user attribute mappings and security level rules, you must access attributes in the SAML response document using an xPath expression, such as /saml2p:Response/saml2:Assertion/saml2:Subject/saml2:NameID/text(). This is because the SAML response is an XML document whereas in OpenID Connect, we use a JSON Path because the response is a JSON-encoded ID token.
Anyone get this working with Azure? We are struggling. Would love to speak with someone who has made it work. Pretty sure we’re missing something on the Azure end with SAML client identity setup, but can’t figure it out. We are getting an error stating that our server is not in the directory of approved clients.
I did get the SAML 2.0 Message when signing on to my e-mail account with ATT.NET, and their system only allowed access to BILLING. There, I discovered that the OAuth or Outlook ( Part of Office Suite by Microsoft ) authentication methods would be required, plus in some instances- Browser selection of IMAP/POP account and a ‘secure key’ derived from the AT & T site. I chose Office 2016 Pro to get a fixed cost rather than leased software (SAS or Software as a service eg. most Office 365 personal ) and can now sign on to my AT & T account. If you Google OAuth, you may find some security concerns depending on version- and it is GNU/GPL licensed which is a different legal deal than Microsoft’s agreement. I suggest you read ahead and note the EULA (user license) terms. Remember that I am the bearer of this news, not the maker.
I am trying to set up a security level rule expression with SAML and am confused on the syntax. the docks say to use {attribute-source:X:Y }
So for your example with /saml2p:Response/saml2:Assertion/saml2:Subject/saml2:NameID/text()
Would it be {attribute-source: /saml2p:Response/saml2:Assertion/saml2:Subject/saml2:NameID/text()}
I have tried a combination different ways and it is not working for me any thoughts on what I’m missing?
That’s a good question, and something that we need to clarify. As of right now, it does not really matter what you put as the “X” since SAML IdPs only have one attribute source (the Authn Response XML), so the system always chooses this attribute source. To be safe, I’d stick with the old {idp-attributes:/saml2p:Response/saml2:Assertion/saml2:Subject/saml2:NameID/text()} format until we give the SAML response xml a name to use in the new format. We’ll probably name it “authn-response” so that the path will look like this: {attribute-source:authn-response:/saml2p:Response/saml2:Assertion/saml2:Subject/saml2:NameID/text()} but I’d rather not push anyone to use that name for the “X” yet until it is released and added to the docs.
I’ve got a SAML 2.0 IdP set up and the roles are mapped successfully /saml2p:Response/saml2:Assertion/saml2:AttributeStatement/saml2:Attribute[@Name='AD_Groups']/saml2:AttributeValue/text(). When logging in, I get the correct role, but can’t get a custom security level to be true. For example, I have Authenticated/Roles/Admin, but don’t have the custom security level using this syntax: containsAny({idp-attributes:/saml2p:Response/saml2:Assertion/saml2:AttributeStatement/saml2:Attribute[@Name='AD_Groups']/saml2:AttributeValue/text()},"Admin"). Any ideas?
Do you have a Value is not a collection exception in your gateway logs? If so, you are probably running into the issue which was fixed by ticket number 1677 mentioned here: Nightly 8.1 Changelogs - 2021 - #51 by KathyApplebaum (which is currently available in the 8.1.5 nightly build). If you are able to upgrade, you could use the new multi-attribute-source bound expression path prefix to signal to the system that you are expecting the attribute value returned to be a multi-valued collection. Example: containsAny({multi-attribute-source:authnResponse:/saml2p:Response/saml2:Assertion/saml2:AttributeStatement/saml2:Attribute[@Name='AD_Groups']/saml2:AttributeValue/text()},"Admin")
Using the multi-attribute-source:authnResponse:XPathToRoles worked in the 8.1.5 nightly. Additionally, I noticed that you can reference user attributes now, so {user:roles} works as well. Looking forward to the stable release of 8.1.5 for our production gateways. Thanks again!