As ALP SaaS evolves, so does the methodology for platform and instance access. Whether users log in through a third party application or directly into the ALP SaaS platform itself, the system has changed the way it understands logins and user access.
Breaking this down can get complicated, so we've created a series of visualizations and explanations to define Enterprise Administration and User Management.
Eventually, this is the core visualization you'll understand. It's the basis for how login and user management works on the ALP SaaS platform and within instances.
Welcome to Tie Town
In order to get this process moving, let's look at a fake company. We'll call them Tie Town. Tie Town is a new client that wants to have access to the ALP SaaS platform and two separate instances. One instance will be for Quality Assurance (QA) and testing and the other will be the official Tie Town production instance with real customers and information. Tie Town wants their employees to use one login to get into all of their ALP SaaS instances.
When it comes to the visualization referenced above, Tie Town is the Enterprise.
We won't configure Tie Town this way, but it's essential to understand the role of an identity provider when it comes to logging into ALP SaaS. An identity provider, at its very basic level, proves the authenticity of a user when they attempt to log in. This can happen locally with a username and password combination in ALP SaaS, or ALP SaaS can seek the authentication from a third party identity provider.
Tie Town could, hypothetically, have their own network of employee facing, individual web applications, like email, a message board, document sharing and a company directory. When Mary Smith sits down at her desk in the morning and logs into her Tie Town customer service account, she could see this slew of web apps. If configured for Single Sign-On, her initial morning login means that she can hop into applications without entering her username and password each time.
ALP SaaS access can be configured in the same way. If Tie Town wanted ALP SaaS to appear in that list of web applications when Mary Smith logs on in the morning, they could set it so that ALP SaaS checks with their identity provider to validate the authenticity of a user and log them into the platform.
What is an Enterprise Admin?
As with all clients, ALP SaaS Support will create the first user and give them the Administrator security role and make them an Enterprise Administrator. From there, it's up to this Tie Town team member to add more logins and connect them to individual instances as users.
The Enterprise Admin manages logins. They create logins and passwords for people who need to access ALP SaaS. They'll bind email addresses to identity providers, whether that's the local ALP SaaS system or some third party like Tie Town.
Back to Mary Smith at Tie Town. The Enterprise Admin wants to add Mary to the Tie Town QA and Production instances. First, the Admin will add that login to the ALP SaaS platform. This action does not get Mary Smith into any instances. Sure, Mary Smith can log in now, but this is the screen she'll see.
Not very useful, right?
Mary's login works, but she hasn't been added as a user. That takes another step.
The Enterprise Admin work stops here. Getting Mary into individual instances falls under a different portion of ALP SaaS entirely.
This is System User Management
When the ALP SaaS Support team spun up the Tie Town account and started their QA and Production instances, they created a login and user with the Administrator security role and made them an Enterprise Administrator. That person used their Enterprise Admin abilities to make Mary Smith a login, and she has access to ALP SaaS. Now they want to add her as a user on individual instances.
Adding System Users can be done by anyone with the right System User Security Roles. That initial Administrator ALP SaaS Support made for Tie Town has the right Security Roles to get Mary Smith in both instances. Any user can have those same Security Roles, too. The Security Roles page in the application is powerful enough to give (or deny) users access to individual pages in the platform, from creating users to managing member enrollment.
That Administrator will need to head into both the Production and QA instances, navigate to the System > User menu and add Mary Smith as a user on each. By matching Mary's login email to the one they used to create her login, she'll have proper access.
Now Mary Smith is a user on both of Tie Town's instances.
Enterprise Admin vs. Login vs. User
Let's put it all together. In our example, Tie Town is the enterprise.
- The first user ALP SaaS Support created for Tie Town had the Administrator security role and was an Enterprise Admin.
- Our Enterprise Admin created Mary Smith's Login, giving her access to ALP SaaS but no instances.
- Then our user with System User Security Roles added Mary to both the Production and QA instances for Tie Town as a User.
Finally, here's our visualization with Tie Town in place.