Will Leaf's Authorization work if users are not a member of any group?

[artgoldberg]

Hi @ndobb

I'm expanding on Discussion #435 .

Our use case is that we want everyone with active network credentials to be able to use a Leaf instance which accesses only de-identified data. I have learned that our Azure Active Directory (AD) service can be configured to authenticate anyone with active network credentials by creating Azure AD application that does not have an AD group associated with it. Thus, everyone who logs in will be authenticated, but nobody will be a member of a SAML group. In this case can Leaf work and what should be the value for Authorization.RolesMapping.User?

The benefit of this approach for our deployment and institution is that the people with active network credentials is a large and frequently changed group. Therefore, it is much more appropriate for our IT security to maintain this set than it is for us.

However, my guess is that this use case is not supported by Leaf because it relies on groups provided by the SAML Identity Provider and the roles in Authorization.RolesMapping to control user access.

I should add that the access mode I'm proposing clearly differs from a setup that does not use authentication.

What do you think?

Arthur

[ndobb]

Hi @artgoldberg,

This sounds like something that could be handled by relaxing the requirement that Leaf users be part of a particular group, specifically this line: https://github.com/uwrit/leaf/blob/master/src/server/API/Jwt/JwtProvider.cs#L69. Is it correct to assume that username and so on would still be present on the SAML2 message?

If that's the case, this could be a new minor feature that allows in any user that has a username (to allow for logging/auditing) or something similar, configured in appsettings.json.

Would that work?

Best,
-nic

[artgoldberg]

Hi @ndobb

Awesome. That's exactly what I was hoping you would say, Nic. Yes, it would be correct to assume that users' identifiers would be present in the SAML2 response.

Regards
Arthur

PS. Our release date has been extended until the end of August.

[lrasmus]

Nice timing on this - we are doing a setup at Northwestern, and I ran into the scenario where our Shibboleth does not return groups as it's configured primarily for authentication. As a workaround, I modified https://github.com/uwrit/leaf/blob/master/src/server/API/Authorization/SAML2EntitlementProvider.cs#L26 to assign groups/roles based on the user. I realize this is far from optimal, but it was a quick win given that we are doing this initially as a proof of concept.

For our implementation, I'm considering implementing some local map between users and groups/roles. I wasn't sure if this would be broadly useful to others, and if it's worth preparing and proposing as a PR. The list could be managed in the appsettings.json to be consistent.

[ndobb]

@artgoldberg and @lrasmus - I've created a new patch branch, 3.9.2, and run it in our development EDW instance and it worked as expected. Can you please give it a try? If it works I'll create a GitHub Release for it.

In order to run it you'll need to add a line to the appsettings.json Authorization section:

Note that RolesMapping:User is not a valid user group (I would hope, anyway), but is ignored because AllowAllAuthenticatedUsers is set to true. The actual code changes are very minor.

Best,
-nic

[artgoldberg]

Thanks @ndobb , I believe this is exactly what we asked for. Nice that few code changes were needed.

I will try it, but that may take some days as I'm preoccupied with building the conditions concept hierarchy now, and need to create a new Azure AD application to test Leaf 3.9.2. I'll report on my results as soon as I try it.

Arthur