We use an external IDP for the main login for operators to access perspective and they have various roles tagged to their accounts based on operators, supervisor, admin, etc. This gives them access for who can change what set points and such but now there's an additional ask for allowing additional bypasses only during certain activities after the user has provided an additional login for that access for lets call it maintenance mode.
So I'm wondering how to implement this. Can Ignition support a secondary local account login within Perspective? Or is there a better implementation for giving them access to a subset of buttons only some of the time. Our safety procedures prevent us from having these buttons available all the time and relying on operators solely following procedural controls.
So far the backup plan is to have them have second email accounts as super users but that's more effort on the account management side and it'd be nice to keep it within Perspective.
The built in authentication challenge might be enough for your use case, but it would require a login operation for each action taken that is locked behind the higher access.
If you use the Auth Challenge functionality (and I think it is your answer), it is up to you to include scripting that logs the relevant time stamps and roles in session properties, and expires on some desired time criteria. (Unless you want to challenge for every operation.)
And yeah we already have audit logs recording every action already and the existing soft bypasses have timers in the PLC that auto turn off unless they extend the duration so should be set on the safety side adding these and using the same format. Just needed a way to ensure they cant be accidently clicked without additional hoops.
We have implemented a similar system where we use the authentication challenge to set a session prop, which requires the same user to be logged in to complete the Authentication challenge.
The session prop is used in the ‘enabled’ prop to enable the selections which require elevation.
So regardless of what level account executes the authentication challenge, everything will be enabled but ultimately we are still using the baked in tag security to limit access to the lower levels. This just prevents using that field to edit the tag
The session prop is setup to revert after some defined time.
This is a pretty straight forward implementation, but does mean you have to set up every element which requires elevation which could result in it being missed.
I’m currently contemplating an alternate solution which actually alters the sessions security so it is baked into every element by default