SAML IDP, User Sources, and On-Call Rosters in scale out architectures

Ignition
,
1

Hello, I am in the process of building out a scale-out architecture which is creating some challenges for me I was hoping the community could help with.

Some details. I am using SAML as an Identity Provider and as of right now we will have one front-end server and one backend server. There may come a time were we have two or three front-end servers so I am trying to think through scenarios before we get too far down the road.

I would like to use SAML for as much as I can since it is how we plan to enforce MFA when logging in to our applications. That said SAML seems to be just an authentication mechanism that isn't fully integrated with some ignition options like user sources.

For anyone curious I did read the Scale-Out Architecture Guide in the manual. It just doesn't touch on all the items I am curious about.
https://docs.inductiveautomation.com/display/DOC81/Scale-Out+Architecture+Guide#ScaleOutArchitectureGuide-EnterpriseAdministrationModule(EAM)

  • When using a SAML IDP how should user sources be configured?

    • From what I have found there is no SAML user source so this leaves me with two options as I see it. Note: I do not have an Active Directory server in this application. Along with that, we do not have the EAM module and it probably won't be in the cards for a while so that is not an option for us. The user source is needed for On-Call rosters needed for alarming.

      • Create an internal ignition user source. Then copy my users from SAML into the internal user source. This isn't ideal in my opinion since each front-end gateway would have a user source that requires additional management. I would prefer a centralized solution for management we may have multiple front-end ignition servers and I have not seen a way to sync user sources between multiple gateways.

      • Use a database user source. I do not have much experience with this method but it seems to provide a centralized solution but still requires copying users from my SAML IDP to a database. That said my IT department would like just the back-end server to have access to our database for security reasons, although this is not set in stone.

  • Is there a remote user source option?

    • I assume the database option kinda fills this role but was curious if there was a way to create an internal user source on my back-end server and then share it with my front-end servers via the gateway network.

  • When using a SAML IDP how should On-Call Rosters be configured?

    • This ties into my first question. What is the best way to create a centralized user source that can be shared with On-Call rosters on the front-end servers so end users can add or subtract users from an on-call list using the roster management tool?

  • What resources would you recommend reading to learn how to build out scale-out architectures?

1 Like
2

Hi,
How you are resolve it?

3

Sorry for the late response. I did not resolve my issues yet but below was the response for IA tech support on the topic.

· When using a SAML IDP how should user sources be configured?

o From what I have found there is no SAML user source so this leaves me with two options as I see it. Note: I do not have an Active Directory server in this application. Along with that, we do not have the EAM module and it probably won't be in the cards for a while so that is not an option for us. The user source is needed for On-Call rosters needed for alarming.

§ Create an internal ignition user source . Then copy my users from SAML into the internal user source. This isn't ideal in my opinion since each front-end gateway would have a user source that requires additional management. I would prefer a centralized solution for management we may have multiple front-end ignition servers and I have not seen a way to sync user sources between multiple gateways.

§ Use a database user source . I do not have much experience with this method but it seems to provide a centralized solution but still requires copying users from my SAML IDP to a database. That said my IT department would like just the back-end server to have access to our database for security reasons, although this is not set in stone.

Correct, there is no option to use an IdP with rosters. For the internal user source, there is no built-in way to synchronize them so you would have to use scripting. We have an example of something like that on the Exchange: https://inductiveautomation.com/exchange/2292/overview

The database option would provide a centralized approach as long as each Gateway could connect to that same database. This might not be necessary though because this likely would just be handled by the back end server only, unless you have multiple back end Gateways that need to stay in sync easier.

· Is there a remote user source option?

o I assume the database option kinda fills this role but was curious if there was a way to create an internal user source on my back-end server and then share it with my front-end servers via the gateway network.

No, though we have thought about that as a feature, there is nothing on the roadmap yet.

· When using a SAML IDP how should On-Call Rosters be configured?

o This ties into my first question. What is the best way to create a centralized user source that can be shared with On-Call rosters on the front-end servers so end users can add or subtract users from an on-call list using the roster management tool?

Managing rosters in a more native way would require one of the methods above using an actual user source. The alternative would be to create your own roster lists that can be used within your notifications. I have seen customers do this through scripting so they can generate the list in the notification block. If your IdP has an API that you can access through this, then you may be able to eliminate the need for managing the user source and instead only manage roster lists (in a db table, for example).

· Is there a remote on-call roster option? This would be like a remote tag provider but for on-call rosters. I do not think this is a thing but wanted to ask.

No, there is no remote on-call roster option, other than using scripting/messaging between the Gateways. One would hold the actual roster while the others would query for it using scripting.

· On Call Rosters. Where should the On-Call roster live in a scale out architecture? I assume on the backend server since that is where the alarms exist.

They would normally exist wherever your notification pipelines are defined because that is where you would access them.

· On Call Roster Management. How can the front-end servers interact and update on call rosters that are on the backend?

Speaking with tech support it sounds like I have two options.

Use gateway message handlers.

Use gateway scoped tags and event change scripts.

Exactly, you would need to provide access to those rosters that are living on the back end. Scripting/messaging, tags, shared database are some examples.

· Is there an existing roster management tool that is designed for front end and backend applications?

The Exchange resource that I linked would be a good start and you could extend it further to include the tools that you need for your application.

· What resources would you recommend reading to learn how to build out scale-out architectures?

I believe you have already read our scale out guide, but that is more about the general setup: https://docs.inductiveautomation.com/display/DOC81/Scale-Out+Architecture+Guide

Besides that, you can also look at our general architecture guide, but again it is more general and not focused on notifications/rosters: https://inductiveautomation.com/resources/article/ignition-server-sizing-and-architecture-guide

We don't really have a guide that would help with this specific use case at the moment.

Based on all of this, it looks like you have a few options:

  • Use an internal user source and rosters on the back end, with messaging to manage those rosters from the front ends. You would need to sync up the user source with your IdP.
  • Use a database as a user source and set up rosters on the back end in the same way as above - I'm not sure if this is going to be necessary unless you have multiple back ends, or maybe if it is easier to keep a database in sync with your IdP.
  • Use calculated rosters to generate the roster in the pipeline. If your IdP has an API that would allow you access to the information you need, then you may be able to omit some of the user/roster syncing with this.
1 Like
4

The real roadblock to any solution is that SAML doesn't define any form of user enumeration. That is simply not part of the standard. When using a SAML IdP, anything that involves getting lists of users, for any purpose, will have to be a custom solution communicating with a custom backend.

It is particularly important to note that such an enumeration API leaks information (identities). SAML itself only provides information about the one identity that is being asserted in the challenge, and only provides it when the challenge is successful. Therefore, SAML does not require the IdP to trust the service that uses it. But leaky APIs need to be restricted to trusted callers, adding a huge layer of complexity. You should not expect SAML to ever have this capability.