After upgrading to v8.1 RC2, an identity provider named “default_0” appeared. I still have an identity provider named “default” and they seem to have the same settings.
Also, the “System Identity Provider” under Config>Security>General was set to “default_0”.
Is there a reason for this? If not, can I delete the duplicate?
This is expected functionality on upgrades to 8.1. The Gateway Web Interface now uses Federated Identity Providers for authentication, and in order to allow for the same users to be able to login to the Gateway Web Interface as before the upgrade, we automatically create a new internal Ignition IdP and point its user source profile to the system’s user source profile. We then set the new “System Identity Provider” setting to this new internal IdP.
The name “default_0” was used because we attempt to name the new IdP “default”, but there was already an IdP named “default”, so to avoid a collision, we append a unique number at the end.
Starting with RC3, we’re actually going to name it “system_default” instead since the “default” IdP will be a common collision scenario on upgrades from 8.0.x.
As to whether or not you can delete it - I’d make sure you set the “System Identity Provider” to the one you want to use for Gateway Web Interface logins before deleting it. I’m pretty sure the system won’t even allow you to delete the IdP if it is used as the System Identity Provider, since you’d lock yourself out (at which point, you’d have to do a GCU password reset and Gateway restart to commission a new admin account, which will also generate a new internal system IdP).
Thanks for the quick reply. I am not very familiar with web security and identity providers, so I have some follow up questions.
Will it now be standard to use two separate identity providers? Perspective sessions use the “default” IdP and the web interface/designer use the “system_default” IdP? Or should the new “system_default” be used for everything?
Also, I am using user grants in the “default” IdP to set security levels in the Perspective session. I’m assuming these don’t need to be duplicated in the “system_default” IdP because that would only be used when logging into the gateway web page or designer.
Will it now be standard to use two separate identity providers? Perspective sessions use the “default” IdP and the web interface/designer use the “system_default” IdP? Or should the new “system_default” be used for everything?
It's completely up to you and how you would like to manage which users can access which areas of the product.
Also, I am using user grants in the “default” IdP to set security levels in the Perspective session. I’m assuming these don’t need to be duplicated in the “system_default” IdP because that would only be used when logging into the gateway web page or designer.
Depends on which security levels you require for the Config, Status, Home, Designer, and Create Project security level permissions settings in Gateway Web Interface > Config > Security > General. On upgrade, we take the old role-based permissions settings and convert them to security level paths of the form Authenticated/Roles/{RoleName} in order to maintain the same effective permissions from the old model to the new model. If you change any of these security levels permissions, you'll need to make sure that you have the necessary user grants / security level rules in place on the system IdP in order to be granted the target security levels.
Thanks. I understand this is all customizable to our needs, but what I’m getting at is why did it need to create a second identity provider? Is the new one doing anything that the original couldn’t do? You mentioned the gateway web interface now uses “Federated” IdP’s for authentication. Is the “default” not “Federated”?
If it is really a duplicate, I don’t see why it is creating the “default_0” or “system_default” in the first place. If it needs an internal IdP, it should be able to see there is already one there named “default” and just use that for the gateway web page.
Sorry if I’m missing something here. Just seems unnecessary.
We create a new internal IdP because that is the only way we can really guarantee the behavior we are targeting on upgrade, which is to allow for users to continue to use the same credentials from the same underlying user source profile and the same permissions in this new IdP-based login model. We do not want to rely upon setting the system IdP to an existing IdP just because it is named “default” because the existing IdP might not have the appropriate role attribute mapping in place or it may point to a user source profile that does not match with what the system user source profile is set to, or an IdP named “default” may not even exist on upgrade. Any of these scenarios could cause many users to run into a broken upgrade experience. Creating a fresh internal IdP in a known state was the simplest / safest approach that we could come up with.
Ah, that makes sense. Thanks for taking the time to explain!