Implementing RBAC using okta - spring-boot

Currently our spring boot app uses okta for login. There is a need to implement RBAC for the application so I was trying to see if I can leverage okta itself for mapping users to specific roles.
I would like to implement the standard RBAC model in which I would map multiple permissions under a role and the roles are associated to users. Basically it involves 3 levels permissions > roles > users.
But in okta I don't see the standard way for mapping roles and permissions. RBAC is achieved by creating groups and associating groups to the users, which is two levels. And groups needs to be added as a custom claim.
How do I achieve the standard RBAC mapping(permissions > roles > users) in okta or it's something that needs to handled outside the IDP provider.
Thanks in advance.

Possible Solution:
You can make the scopes (scp in access token) be your permissions. Below are the steps:
In your Authorization Server, create your custom scopes(permissions) and set them as default scopes (this is necessary).
For example create 2 default scopes:
books.read (default=true)
books.write (default=true)
Go to access policies in your Authorization Server create one if none is defined.
Create access policy rules in the access policies page, the rules will be your mapping between groups and scopes.
Test that in Token Preview tab, the trick here is to leave scopes field empty so that the Authorization server can return the default scopes that are set for the user, as explained by Okta:
A default scope will be returned in an access token when the client omits the scope parameter in a token request, provided this scope is allowed as part of the access policy rule.
Now in your application when requesting an authorization code make sure that scope query param is empty.
Depending on the library you are using you may face some issues if by default they are expecting an id_token to be always returned but you will probably be able to customize it. For example: https://github.com/okta/okta-auth-js/issues/827
Solution Limitations:
As mentioned in steps 4 and 5 we are omitting the scope query parameter, this mean that only our custom scopes assigned for the user or his groups will be returned, since the base scopes that are predefined by Okta such as profile, openid, email ... will not be returned. Which also means that we are skipping OIDC which needs the openid scope, so id_token will not be returned and only an access_token will. So this solution assumes that you don't need any of the base scopes predefined by Okta.
In case you need any of the base scopes
As described in the limitations, the solution assumes that you don't need any of the base scopes predefined by Okta. But in case you do then below is a solution that works in that case but not that nice.
When requesting an authorization code in the oauth flow, you need to send the request twice
first one: omit scope query param, so the default scopes are returned.
second one: append the returned scopes returned from the first request to the list of base scopes you wanted such as openid, profile, 'email`. So you would send something like (encoded already)
?scope=books.read%20books.write%20openid%20profile%20email
Disclaimer:
The above solution may not be recommended, but it works. If anyone can find any security issues with the above solution please leave it in the comments.

When you get into the details of roles and permissions, the data tends to be domain specific and to change often. I would advise against trying to manage it in the Authorization Server.
One design pattern that will give you full control over claims is to form a custom AuthenticationPrincipal that includes roles or permissions from your application database(s).
If interested in this pattern, see these resources of mine:
Custom Claims Blog Post
Java Custom Claims Code
How to run Java Code Sample

Related

Spring security user based permission? (not role based)

Assume I have a database composed of user and projects. A user has a one to many relationship with projects. The user can do operations using rest endpoints.
The problem is:
how can I verify that this user owns this resource?
I don't want a malicious user to change an id then suddenly he views another person's project details/images/etc. Think of it like a social media (my app is not a social media but trying to illustrate the issue): where you can view only your images but not another person's images despite having the same "status".
Most spring-security blogs online is using a role based approach. I have no idea what to even search for in this case (tried multiple search queries to no avail).
One option is to run some sort of multijoin query on every resource request/operation till I reach that resource id and check it's owning user to check if it is the logged in user. However, I am not sure if this way is efficient since there are multiple tables in a chain in the real app (could have a lot of joins if I go this way manually; example: user -> project -> tasklist-> ... -> Note; deleting a note would trigger a large chain) or how to make the "authorizer" use it.
what are my options?
In case it matters:
I am using spring-boot + hibernate/JPA + spring-security
Spring Security has the following concepts:
Authentication:
Proving the an actor is who it vouches to be. Authentication is done using credentials, where credentials can take any number of forms - username/password, token, hardware key, etc.
You can set up Spring Security with a set of acceptable authentication providers.
Authorization:
Given an authenticated user, deciding if that user has access to a given resource. Where the resource can be:
An HTTP endpoint.
An Java Method.
A property of an object.
What you want to do here is provide a custom authorization scheme.
You can read about Spring Security's authorization architecture here, including how to set up custom authorization. Once you're ready you might ask specific questions as you go.

WebAPI 2 Authorize Roles with MSAL

I'm in throws of moving our security architecture from ASP.NET Core Identity to Azure AD V2 with MSAL.js. We used a lot of Roles with the ASP.NET Core Identity implementation and the information was managed in the database using the web application. The pattern I'm abandoning is similar to this one.
https://www.dotnetcurry.com/aspnet-core/role-based-security
Azure AD with MSAL is working. The tokens are being created and passed and the local Web API Endpoints decorated with the generic [Authorize] attribute are being honored as you would expect. Web API Endpoints decorated with [Authorize(Roles= "Fee, Foo, Fi, Fum")] are throwing a 401 unauthorized error.
I'm not sure where to go from here. Do I write a CustomAuthorize attribute override for Web API and go back to the database and grab the roles. (probably match the DB defined roles to the user based on email address)
OR
Is there a way to implement roles natively with Azure AD V2?
I'm not sure whats the best course of action from here. Documentation and Code samples seem limited. It would sure be nice to just throw a AD User in a Group and have the Group be respected as a Role in the Web API. On the other hand, It's nice to have Role delegation handled within the confines of the Web Application.
Any advice, experience or interest would be greatly appreciated.
Answer
Follow up to my question. #Marc , You're correct, after looking at the token the Roles are not present. Adding Roles to the token seems pretty straight forward. You need to Patch the graph schema to include them, Configure the roles and assign them to users as needed thru AAD.
Or that's how it looks at first glance. After digging a deeper, it requires a P1 or P2 Enterprise license which only costs an additional 6$ per month per user. This will literally double the cost of hosting email in the cloud for us.
Alternatively I wrote a CustomAuthAttribute for WebAPI and tied User & Roles together on the server backend. Roles can still be managed via the web application and users can still login using Active Directory Credentials.
I recall that the id token returned in implicit flow (the one you use with JS) does not include app roles (or groups). I cannot find any docs confirming that but see others who got around the issue (so the issue must be there) by using Graph to get the roles (or groups).
You can capture the token you receive from AAD and view it using https://jwt.ms to see whether roles are included in it.

Okta not returning custom claims in tokens

I just signed up for a dev test account with Okta to test OIDC using Okta's auth service and user management.
Using their management portal, I created a second group called Test Group along with the default group of Everyone and added my single user to both groups.
I then added an application called My SPA and assigned the Test Group access to this application.
Using the classic UI, I then edited the OpenID Connect ID Token section and set Group claims type to Expression and added groups as the claim name and getFilteredGroups(app.profile.groupwhitelist, "group.name", 40) as the expression.
I then went and edited the authorization server. I added a claim called 'groups' with a RegEx of *. to be used with any scope, access tokens and always include.
I then use the Token Preview selecting my user and using implicit grant flow but no groups show up.
How do you get a user's groups to show up as claims in the ID or Access Token from an Okta auth server?
Edit
Screen shots of what I have:
I’ve only ever used the Developer Console to configure things. Here’s how I did it:
Navigate to API > Authorization Servers, click the Authorization Servers tab and edit the default one. Click the Claims tab and Add Claim. Name it "groups" or "roles", and include it in the ID Token. Set the value type to "Groups" and set the filter to be a Regex of .*.
You need to add the "groups" scope. In the scope, add "groups" in addition to profile and openid
I think the Groups here are created in order to park users in respective buckets (e.g. Admins / Users etc) so that by knowing the Group of User, the role can be derived for Authorizations.
However, I will recommend to use Okta's Custom Attribute in Users' Profile so that the User Info can have required attribute.
The Custom Attribute can be set as Dropdown styled Enumeration to choose from and can also be marked as Mandatory while adding User in system.
https://support.okta.com/help/s/article/How-to-create-dropdown-enumerated-custom-attributes-in-Okta?language=en_US
Adding Custom Attribute - https://help.okta.com/en/prod/Content/Topics/users-groups-profiles/usgp-add-custom-user-attributes.htm
And Mapping Attributes to Okta Profile -
https://help.okta.com/en/prod/Content/Topics/users-groups-profiles/usgp-about-attribute-mappings.htm
Hope this also helps.

what values i can pass to scope apart from empty string ("") to OAuth2Authenticator constructor in Xamarin.Auth?

What values i can pass to scope apart from empty string ("") to OAuth2Authenticator constructor in Xamarin.Auth?
Please refer to the below link for more information
on OAuth2Authenticator usage
https://components.xamarin.com/gettingstarted/xamarin.auth
Well It depends on the Authentication Provider you are making use of.
Let me explain you this in detailed,
say for example ,
you want to authenticate users by their gmail accounts in that case
,you can use following scopes
https://www.googleapis.com/auth/plus.login
https://www.googleapis.com/auth/plus.profile.emails.read
For more information on OAuth with Google , you can refer to https://developers.google.com/+/web/api/rest/oauth
You can refer to the below link for scope values ,if you want to authenticate users using Micrsoft as third party Authentication provider
https://graph.microsoft.io/en-us/docs/authorization/permission_scopes
Similarly for other providers , check corresponding website documentation.
Hope this helps.
OAuth 2.0 Scopes are normally used to define what type of access (permission) that you are requesting. Thus if the access token is granted, only those scopes are assigned to that token, if you need to change the type of scope/permission needed say from a "read_only" scope to a "readwrite" scope, you have to request a new token using the new scope.
Scopes are dependent upon the service that you are trying to access and will be defined by that service, they are commonly used scopes, like "read_only", but again, the service defines what they are.
I.e. To ask for permission for read and write permissions and offline access at the same time to user's Microsoft OneDrive account you would ask for this scope:
"onedrive.readwrite wl.offline_access"
To access a Google Calendar, you might ask for only view access (read only) via the scope:
"https://www.googleapis.com/auth/calendar.readonly"
To change/manage the user's calendar, you would ask for:
"https://www.googleapis.com/auth/calendar"
When requesting multiple scopes at one, you might need to separate each scope by a space or a comma or some other service defined delimiter. While the space delimiter is very common, again this is defined by the service you are interfacing.
Ref: Access Token Scope / https://www.rfc-editor.org/rfc/rfc6749#page-23

Changing request level for google project

How do I lower the requested access level of an existing google project?
It's currently asking for:
View your email address
View your basic profile info
Manage your contacts
When all I really want is to authenticate a user for login purposes, and I think all I need for that is:
Have offline access
One of the parameters you are passing when you create a credential is called scope, and contains a list of each of the services your users must authorize.
From the OAuth 2.0 docs, scope contains a string or iterable of strings. Change it to the new scopes you want.

Resources