@jspecht is there a way we can manually specify IDP entity ID?
Now this is automatically picked up as the gateway DNS but in order to manage a large number of instances from one single IDP federation, we need to be able to use the same entity ID for each of our ignition instances.
Thanks,
Nick
There is not a way to manually specify Ignition’s SP Entity ID, which is what I believe you are asking?
You are not the first person to ask, and we have a ticket in our backlog to address this.
Correct. Thanks for verifying.
For now we will continue to get a new federation connection per Ignition VM but this will add up and become cumbersome to manage quite rapidly because we will be greatly expanding the # of instances of Ignition.
When it is released how can we be notified of it? We will have a backlog of work then to go update all the existing instances in production.
Thanks,
Nick
I've linked our internal ticket to this forum thread so that when it is released, someone should reply back to this thread with the news. You can also keep an eye out for the nightly build thread referencing ticket 2155
To give some nuance what needs to be parameterizable is the saml:Issuer attribute in the SAML request.
Decoding the SAML request and pretty-printing the XML we see every gateway sends its own hostname as the identifier.
If we could set this attribute using a single identifier, it greatly simplifies certificate managnement required for the army of gateways.
Thanks for the information. Ticket 2155 that I have referenced will solve this problem by exposing a new SP Entity ID setting in the SAML IdP config. By default, it will be in “auto” mode (which behaves as it does right now, using the incoming request’s Gateway URL as the SP Entity ID), but you will be able to disable the auto mode and specify your own hard-coded SP Entity ID to use instead. This is what is used as the Issuer in SAML request XML documents originating from the Gateway.
@jspecht @jsorlie it seems that our internal organization SAML IDP provider would begin disallowing us to have 1 IDP per each gateway. They want us to use one single IDP connection for all Ignition applications. We cannot do this until feature 2155 is released. We have been in contact with @Travis.Cox and he has let us know it has been prioritized.
We really need this soon, at present we have 32 SAML IDP connections.
Thanks,
Nick
Hi @nicholas.robinson -
The ticket is currently being implemented by a developer. We’ll reply back once it has been merged into the early access build.
@jspecht @Travis.Cox we really need IA to release this feature. We know you have told us it is being worked on but today we were told internally that we have to update all of our SAML certs. At present this means doing it manually on 59 gateways.
If we had feature 2155 we’d only have to update 1 cert. Please help us prioritize getting this feature released.
Thanks,
Nick
This feature was merged in earlier today and will be a part of tomorrow’s early access build.
Here are a couple of screenshots of the new configuration mockups:
As you can see: there is a new “SP Entity ID” setting which has checkbox “Automatically generate the SP Entity ID based on the hostname that the client uses to connect to this Gateway” checked by default for backwards-compatibility. The checkbox can be unchecked, at which point the text input below may be used to populate whatever static string you want to use for Ignition’s SP Entity ID.
What was previously the “Entity ID” setting is now renamed to the “IdP Entity ID” setting.
We also offer the capability to configure a completely separate set of config settings for the backup Gateway, which may be required in certain cases, though by default, the checkbox for “Use the same Provider Metadata Configuration for Redundant Backup” is checked, meaning the backup and master Gateways will use the same settings (which is how it has always worked).
These changes apply to the OIDC and SAML IdP types. They do not apply to the Internal Ignition IdP type, since redundancy is handled internally by this IdP type.
Let us know how this works out for you!
Nitpick: section heading states Import Provider Metadata for Redunant Backup
Good catch. Looks like the typo only exists in the mockup, not in the actual product.
Today I tested the user specified Entity ID field with a common IDP cert (one cert, one entity ID, multiple ACS URL’s) and it worked well, no issues noted.
So, thank you very much for getting this in place.
We still have two key sustainability issues we are looking at for our growing fleet:
Thanks,
Nick
That's great to hear! Thanks for the feedback.
Regarding your two outstanding challenges:
- How to update SAML metadata on each of 100’s of gateways
We have a ticket in our system which aims to solve this problem the following way: first you enter your IdP metadata URL as a stored setting in the SAML IdP config in Ignition. Then, at the time of authenticating the user, Ignition will check if it has a key or certificate to verify the saml response signature, and if it doesn't, it will make a request to the IdP using the metadata URL to load the latest keys / certs, and only then if the appropriate key / cert cannot be found, the auth request will fail. This is sorta how OIDC IdPs work when you have the "Use JWKS URI" setting enabled. Think of it as the Gateway automatically reloading the latest trusted keys / certs from the IdP.
This solution does require that each Gateway can communicate with the IdP, though. Does this solution sound like a good fit for your situation?
- How to do SSL cert change over on each gateway when SAML has SSL dependency
I do not understand this. In what way does SAML have an SSL dependency? When you say SSL, are you talking about the SSL certificate that is installed on the Gateway's web server?
Edit: I just read your post here: SSL Cert Switch Over Best Practices
So I am assuming that the dependency of SAML on the SSL cert simply means that your ACS URL needs to be https:// as per your IdP's requirements, and if SSL is not installed on the Gateway at any given point in time, the Gateway will have an http:// URL, which will not match the SAML ACS https:// URL, and so SSO will fail when trying to login using the SAML IdP over plain http. Please confirm my understanding.
All of our gateways (client, designer, gateway) are 100% SSO login using SAML. Basically we always have connection to the IDP so a metadata update solution that relies on that connection, would work.
Regarding SSL/SAML IDP dependency, what you have said is correct. The ACS URL on the idp for each gateway has https/8043. If we remove the SSL cert, that changes to http/8088. I think we could not make calls to the IDP but even if we could the destination in the response would not match.
Thanks,
Nick
Thanks for the clarification. Hopefully your second challenge will be addressed in your other thread. And once we merge in the work for the ticket I mentioned, your first challenge should be addressed 
