Can You Limit a User's Login/Authentication Access to Applications within a Single Tenant?

wc-fa

The product is great, but I appear to be missing something fundamental about the solution's use case.

I have a single Tenant with four (4) Applications and ten (10) Users defined. I want 3 users to have login access to all four Applications, and 7 users to have login access to only of the 2 applications. However, it appears that anytime I add a user to the Tenant the user receives "login/authentication" rights to all 4 applications.

Before installing and setting-up FusionAuth, I thought I would be able to use the "Groups" feature to create a group called "Group-A" that would "grant" login access to all 4 applications and another group called "Group-B" with "grant" login access to only 2 applications. I would assign the 10 users to either Group-A or Group-B and limit which user could login/authenticate to a particular application.

This does not capability does not appear to exists. What am I misunderstanding?

robotdan

I think the confusion is the difference between authentication and authorization.

I don't know if you're using the Login API or an OAuth2 grant, but the same will apply to both scenarios.

Let's say Bob has access to Applications 1-4 of the 10 applications, and Lisa has access to Applications 8-10 of the 10 applications. The way you grant access to a particular application is a User Registration, a registration is the connection between a User and an Application. Once registered, a user can have 0 or more roles as defined by the Application.

Here is an example login result that you're likely seeing:

Login results for Bob:

Bob --> Login to Application (1-4) --> [200] Authenticated
Bob --> Login to Application (5-10) --> [202] Authenticated not registered

Login results for Lisa:

Lisa --> Login to Application (1-7) --> [202] Authenticated not registered
Lisa --> Login to Application (8-10) --> [200] Authenticated

In addition to this status code, the JWT that is returned from the Login API will not contain the applicationId or the roles claim because the user is not authorized to the requested resource (Application).

In other words, FusionAuth has successful authenticated the user because they exist, and the credentials they provided were correct. But if the user is not authorized to the Application, a 202 will be returned the access token (JWT) returned will not contain authorization for the resource.

We do have some configuration in plan to allow this behavior to be configured per application. Once available this configuration would allow you to specify if you want this login request to return 401 to indicate the user is not authorized to the requested resource.

Additional context see Login API.

jonny

@robotdan said in Can You Limit a User's Login/Authentication Access to Applications within a Single Tenant?:

We do have some configuration in plan to allow this behavior to be configured per application. Once available this configuration would allow you to specify if you want this login request to return 401 to indicate the user is not authorized to the requested resource.

So would I be right in thinking, currently FusionAuth can't stop someone with an authenticated account using a application, but this is coming?

So basically is up to the application itself to check if they're authorised to use the app?

Jonny

dan

So would I be right in thinking, currently FusionAuth can't stop someone with an authenticated account using a application, but this is coming?

I'm not sure of the roadmap for this configuration, but right now someone can successfully authenticate, but as @robotdan mentioned, if they aren't registered for a FusionAuth application, you'll get a different http status code. If they are registered with the FusionAuth application and login, you'll get a 200, if they are are not, you'll get a 202. It's up to your program to notice the difference and in the latter case deny access. Another option is to examine the returned JWT. In the 202 case there will be no roles or applicationId provided in the JWT.

So, to sum up:

status code 200 == user authenticated and can access this FusionAuth application
status code 202 == user authenticated, cannot access this FusionAuth application
status code 404 == user not authenticated (doesn't exist or password incorrect)

robotdan

So would I be right in thinking, currently FusionAuth can't stop someone with an authenticated account using a application, but this is coming?

So basically is up to the application itself to check if they're authorised to use the app?

A better way to think about this is to separate authentication and authorization. FusionAuth will always authenticate the user because a user exists in the tenant, so if the user presents a valid username and password they will be authenticated.

FusionAuth then hands you back information about the user so you can authorize them based upon the authority the user has been assigned to the application - specified by the request parameter applicationId (or client_id in OAuth land)

So basically is up to the application itself to check if they're authorised to use the app?

This is correct.

However, even if FusionAuth were to reject the login request because the user was not registered to the application, it would be a mistake for you not to still perform an authorization check on the user.

The user may have an admin role, or a user role - so there will always be a need for you to verify the integrity of the JWT FusionAuth returns to you. These checks include verifying the signature to ensure FusionAuth signed it, not expired, the JWT is intended for your application (generally done by checking the aud claim), and then that the the JWT contains claims that indicate the user can perform the requested action. This can be done by checking the applicationId and roles claims.

There is an open issue to configure the Login API and related OAuth grants to optionally reject the request if the user is not registered to the application. Even with this feature, you'll still always need to be performing additional authorization checks to ensure the response is valid and the user has the necessary permissions.

See https://github.com/FusionAuth/fusionauth-issues/issues/439

Hope that helps!