In-App SSO Security Management

When you add a new OpenVMS user, does it automatically create a constraint within Role-Based Security to allow In-App SSO to Atrieve Web?

If the OpenVMS password change utility wrapper is called during the user creation, then yes, the Role-Based Security constraint for Atrieve Web credentials will be created automatically. If not, the first time the user runs the Atrieve Web product, they will be presented with a username and password prompt. Upon successful login, the Atrieve Web product will automatically create the Role-Based Security Atrieve Web credentials constraint.

Users cannot login with their full district domain email address or Users cannot login with their principal name

Before In-App SSO was introduced, a district could have their login configured to accept both the user’s principal name (ie. firstname.lastname) or their full domain name (firstname.lastname@district.ca). Entering in credentials in either format was accepted to log in to Atrieve.

When In-App SSO is enabled, a district can be configured so that users can either log in with their principal ID (ie. firstname.lastname) or their fully domain name (firstname.lastname@district.ca). The login process CAN NOT support both formats.

If the district is configured to only accept the login name (without the domain), the user will need to type in their credential accordingly.

            Ie. firstname.lastname

If the district is configured to only accept the fully qualified email address, the user will need to type in their credential accordingly.

            Ie. firstname.lastname

We encourage districts to send out a reminder to all their staff about their required login format.

Is there any Audit or Activity logging for In-App SSO logins, logouts, and impersonations?

Yes, there is full logging available indicating all activities within the In-App SSO service. This process is automated and happens on every interaction with the authentication service

If I impersonate an employee, how do I know which Menu is shown? Does it come from Atrieve, Security Builder, Menu Builder, or some other override?

When you impersonate someone else, you are essentially becoming that employee in every aspect.

The system cannot tell the difference between a normal user logging in and accessing the application or an impersonation of that user.

• The flow of security remains the same as with non-SSO processes.

• You can always verify your security values using the User Hub which is available by clicking on your employee name in the bottom left-hand corner of any screen in the application.

• Any impersonated values will display and a message stating an impersonation has occurred will also display if an impersonation has occurred.

The flow of authorization is as follows:

1. Retrieve the Atrieve security for the employee

2. Check Security Builder to see if there are any overrides for that employee, if so, apply them over top of any existing security from step 1

3. If impersonating, apply any changes from the impersonation screen over top of any existing security from step 2

4. Check Menu Service and see if the user's role is present, if so, apply the menu that corresponds to that role. If the user has a Menu Service override, apply that menu over top of any existing menu that has already been retrieved

5. Check Role-Based Security and apply any permissions or constraints required (if applicable)

If you would like to visibly see what Menu is being applied to the currently logged-in user for step 4 above, you can inspect the following screen.

• The first box tells you that the Role exists in Menu Service and has a menu associated with it.

• The second box tells you whether or not the user has a menu override to apply a different menu other than their role menu.
  
  

  

Are there any reports that show which user/employee accounts are associated with In-App SSO?

Yes, there are two reports available within SMS via Atrieve Web that you may run to see which accounts are inactive, which are active, and which have their Role-Based Security Atrieve Web credentials constraint setup.

The SMS Employee Settings Changes/Inquiry screens will indicate which OpenVMS user account is associated with which employee number:

There are two Security Reports available which allow you to look up which accounts are set up correctly and which are not:

1. Employee Number report - shows OpenVMS accounts that do NOT have an employee number associated with the SMS system

2. Employee Role Based Security Report shows which accounts do not have a Role-Based Security Atrieve Web credentials constraint setup

What Happens if the VMS System has a Password Policy in Effect?

If your account currently does not have an SSO Role-Based Security constraint setup, upon your first successful login, the system will automatically attempt to create the constraint for you.

• If the VMS system does not have a password policy in place, the constraint will be automatically created

• If the VMS system does have a password policy in place, the system will attempt to create the constraint by running your current password through the policy. If your current password does not meet the password policy, no constraint will be created, and no message will be displayed. To see the message, you can perform one of the following operations:

1. Create the Role-Based Security constraint using the Role-Based Security application and it will tell you what violates the password policy, or,

2. Change your VMS password and it will also tell you what violates the password policy

Once your password meets the password policy requirements, the constraint will be created as required.