R&D: LDAP/Active Directory authentication

[dan-bowerman]

Do the frameworks we use have libraries/plugins for LDAP/Active Directory authentication? There seems to be a decent amount out there about Vue3 and authentication.

The ATM project has done stuff with this recently, colleagues in the BAAP have most certainly done this sort of thing too, but probably not in Vue. The fundamentals of interacting with LDAP should be the same.

Questions/Proofs-of-Concept:

• [ ] Can we do a basic authentication? e.g., throw an authentication check at the top of the editor landing page: input your ECCC username and network password, verify successful authentication. We don't need to bind this to anything yet.
• [ ] How should we manage the list of "verified" authenticated users? From a purely technical standpoint, what's the best/simplest approach to validating a user is welcome in the system? It should be easy to manage, and something modifiable after deployment.
• [ ] How should we restrict users? Do we need to worry about account types, or just have one user type for standard editing?
• [ ] Should we use this account access for anything other than authenticating? e.g., writing to file systems, uploading to Git, etc.

Let's keep the conversations around specifics surrounding ECCC's authentication infrastructure in Teams.

[milespetrov]

Can we do a basic authentication? e.g., throw an authentication check at the top of the editor landing page: input your ECCC username and network password, verify successful authentication. We don't need to bind this to anything yet.

For an Azure hosted web app, we would be using Microsoft Entra ID. The first step would be to request an app registration to CCOE.

Once we have an app registration there are many ways to implement the authentication with MSAL. It would either be implemented server side or client side but the user flow would be the same. The user would be redirected to a Microsoft Entra signin page where they input their Windows AD user/pass and are then redirected back to the app.

How should we manage the list of "verified" authenticated users? From a purely technical standpoint, what's the best/simplest approach to validating a user is welcome in the system? It should be easy to manage, and something modifiable after deployment.

Entra Id supports requiring user assignment. It should be possible to create a group that represents a storylines project, and assign users into those groups for access.

How should we restrict users? Do we need to worry about account types, or just have one user type for standard editing?

I think we should keep it simple for now, all users in a storylines group can modify it.

Should we use this account access for anything other than authenticating? e.g., writing to file systems, uploading to Git, etc.

The web app should handle any other interaction with other services, including handling the upload/download of blobs from file storage and to determine if the user is allowed to perform these operations on a specific blob (based on the group). Blob storage supports versioning similar to how git does. But if we want to use git and a tfs repo the web app would be initiating these calls as well.

** It's not entirely clear if we would be able to create groups or if these are managed at a higher level. The alternative to groups in Entra ID for us would be roles created in the web app. We would then assign a role (like project1-member) to users of that project. The web app would read the users roles to determine what actions are allowed.

SWIM v3 has implemented MSAL.js in Vue with Azure AD B2C and it works well.

[dan-bowerman]

Thanks for the assessment, @milespetrov. Is Entra ID an option on our on-premises internal architecture? It's unlikely we'll be deploying to an Azure-based environment anytime soon, and talks with CCoE are completely stalled at present. The concepts seem like they could still apply directly to our internal AD on an internal Dev Server?

[milespetrov]

When speaking with Fred who leads the swim api authentication work he mentioned that it would be easy to use ntlm / windows AD. The only issue with internal architecture is the lack of documentation and samples. From what I gathered so far, the server would be a .net c# project and there exists an authentication nuget package for internal apps to use. I'll ask Fred when he's in about this package and hopefully there are some resources around it to get us started.

We would need to rethink how users/groups and roles/permissions would work on internal hardware given what is provided. One possible way forward is to hardcode permissions into the app with something like a permissions config file containing usernames and their respective project(s). The app would get the username from authentication and then check its config to see what actions the user can perform.

[milespetrov]

From Fred:

You only need to ask with to turn it on, after that you only need to "use" it from your app, it will be in the http context user object as identity

There isn't any repo or nuget package we can look at for documentation. The next step is to ask wig to host a web app so we can look into the built in authentication.