Please describe available single-sign on, LDAP or other enterprise-level authentication methods

[mewalig]

The user manual (https://github.com/awslabs/aws-saas-boost/blob/main/docs/user-guide.md) would be more complete if it described options or limitations relating to enterprise sign-on management.

A common on-prem scenario for enterprise software is that the "tenant" is an enterprise that has many users, where users log into their enterprise environment by logging into their Windows machine using credentials that are authenticated via Active Directory. The users then have access to their enterprise applications, which integrate with AD so that the apps can authenticate the user without requiring the user to explicitly log into each app again.

What becomes of this scenario if the app is migrated via SaaS Boost? The documentation says virtually nothing about how or whether single-tenant-multiple-users would work:

• is every tenant supposed to be an individual user? or can a tenant be an organization, under which there will be multiple users?
• in any case, if the on-prem app uses single-sign on to authenticate a user, what does that look like from the user experience when this app is migrated via SaaS Boost?

---

This is a 📕 documentation issue

[brtrvn]

Thank you for your question. First, let's clarify that there are 2 types of user management that we must concern ourselves with.

1. The first are the SaaS provider's employees/users who manage the SaaS platform.
2. The second are the users of the SaaS provider's customers (tenants) who access the SaaS application under the context of the tenant they belong to.

You are talking about the 2nd type of user -- tenant users who are using the SaaS vendor's application (not SaaS Boost). The current version of SaaS Boost does not offer an integrated identity module like it does for billing and analytics. This is on our roadmap and we love to hear feedback on the types of features that would be most beneficial. You have mentioned single sign on (SSO) and integration with a 3rd party identity provider (MS Active Directory). Both of these are on our radar.

Tenants are organizations as you describe - each with their own set of 1 to many users who access and use your application. Your application is hosted/provisioned by the SaaS Boost environment, but how your application deals with users is currently up to you.

What SaaS Boost does provide today is support for the 1st type of user listed above -- SaaS provider "system users". These are users (employees/contractors) who are allowed to auth into the SaaS Boost administration web app in order to configure the SaaS Boost environment, manage tenants, view operational insights, and manage other system users. Extending the feature set of the current system user management is also on our roadmap. We would like to add functionality such as user roles to limit access to certain features of the admin app.

I think I will need more details about your specific use case, but however your application is dealing with tenant user identity and authn/z today would still be your responsibility in SaaS Boost until we add some kind of identity module to the platform.

• Is your application deployed in your customer's environment today alongside their AD instance?
• Is your application deployed in your environment today and you setup networking and trust between your environment and the customer's AD instance?
• Is your application deployed in your environment today and you maintain an AD instance in your environment that your app auth's against and your AD has a trust relationship with the customer's AD?
• Another wiring I'm not thinking of? :)

Each of these scenarios can be supported with AWS tooling, but you may have to extend the SaaS Boost environment to support it.

[mewalig]

Thanks for your response. Here is the current situation I would be interested to know whether SaaS Boost can assist with:

1. Before the customer uses our product, they have their own corporate network. When their users go into the office (physically or virtually), they log into a Windows workstation (physical or virtual), with credentials that are managed through Active Directory, which is administered by their internal corporate IT department.
2. When the customer uses our product, their IT department will provision an internal server to run it, which creates an internal website-- let's call it https://ourproduct.internal.com. The customer's IT department creates an Enterprise Application in their AD Portal, and then passes on the information from that step to configure our product to integrate with their AD through SAML single-sign on
3. After the above step is done, the end user experience-- ie the customer end users, not the customer's IT department-- is:
   • Log into work as usual (Step 1)
   • To use our product, navigate browser to https://ourproduct.internal.com
   • Because our product has integrated with their AD, no further sign-in is necessary for our product to know who the user is and skip an explicit login step

For any SaaS alternative to the above, it would be ideal for the user experience described in step 3 to be unchanged,(other than the specific URL where the product is access from). At the least, if the experience would need to change, we'd want to be able to describe the new experience with specificity before deciding whether to make that change, and in any case, to describe what steps the customer IT would need to take to accommodate.

As an aside-- in some, but not all, cases, the primary reason preventing all of the above from being done through a central, multi-tenant server, is the customer's data security policies, which are sensitive to privacy laws such as the Gramm–Leach–Bliley Act and its European brethren. While these policies are becoming more open to using cloud services in the context of private cloud (which, from the perspective of vendor deployment of a solution, is no different from on-prem, unless I'm missing something), they still do not go so far as to allow the customer to put their data into multi-tenant SaaS solutions, at least unless those solutions have come up with some new way to address security that I haven't yet seen.

Hopefully that answers your questions-- please lmk if not