Does Hasura generate Role-based introspection? - graphql

I want to build an admin tool based on a Hasura backend.
Different users will have different level of access based on roles.
Will I be able to do introspection per role and therefore know which fields (from queries) and buttons (for mutations) to show?

After clarification from OP it became possible to answer this question.
Yes. Hasura generates different schema for different roles.
How to check them?
A. Permissions summary
Go in hasura console to https://[hasura address]/console/data/schema/public/permissions
You will see something similar to:
Note here:
admin role has access to all registered objects and all fields
other roles have access to different sets of objects and different set of fields with different row security checks.
B. Hasura API Explorer
Go to: https://[your hasura]/console/api-explorer.
Set x-hasura-role in Request Headers:
Try to do queries and mutations.
You'll see that sets of objects and fields are different for different roles.
C. Allowed List
If you activated Allowed List (which is recommended for production)
(and if graphql inspection query is not in your Allowed List )
then graphql inspection will be disabled for all roles except admin:
For those who are interested in enabling introspection query - check https://github.com/hasura/graphql-engine/blob/master/server/src-rsr/introspection.json

Related

Spring Security: Creating multiple entry point for securing different rest controllers

I'm exploring the Spring framework, and in particular I am working on a Cinema Management Application that will be connected to a React.JS SPA (Single Page Application).
The problem is the following. On my database I do have three different tables representing three different types of users, namely Admin, Customer, and Cinema_Employee.
For each type of user, I created a #RestController with a list of RequestMethods that a particular user is able to perform:
"/admin"
"/customer"
"/employee"
What I am trying to achieve now, it's to secure each endpoint offering three different login pages that will handle the authentication the respective type of user.
How can I set up three AuthenticationManager that handle different Authentication objects within a SecurityConfig class given these requirements, and most importantly, how can I override the Authorisation mindful that each user once has logged in, will have access only to the respective endpoint?
I looked carefully at other examples online, and most of them are radical different, following a pattern where the database has another additional 'Authorities' table aside the 'user' one that stores the credential. In my case this solution cannot be applied, not only because the whole design would become redundant, but also because the name of the table where the application will perform the authentication check against, explicitly imply the authorisation that a given user has inside the system.
Your design sounds strange to me.
A user should have a role, e.g. Admin, Customer, Employee and based on the user's role he gets access to methods or not. Have a look at role based access control concepts. For Spring Security there is for example this tutorial:
https://www.baeldung.com/role-and-privilege-for-spring-security-registration

Implementing RBAC using okta

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

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.

ServiceNow API - How to get all users and all their attributes

I am trying to use the ServiceNow API for the first time and I need to get a list of all the users in the sys_user table with all of their available fields/attributes like date created, updated etc.
I tried GET request to this URI:
https://myinstance.service-now.com/api/now/table/sys_user
But the response only returns the Users and some of their attributes but not all of the ones I can see in the portal.
What is the correct URI to make the REST call to get all users and their fields/attributes?
I'm assuming you want to access SN API from another application? Cause if you want to do that from within SN, there is the GlideRecord server API you can use.
Now when you access the table API from external source, you do that through a registered user - depending on this user and their roles, you might see all or only some of the user attributes. Also, if you add specific Query Parameters to your request like sysparm_query or sysparm_fields, this will limit what you get.
ACLs (Access Control Lists) is the mechanism in ServiceNow restricting access to Table API. So I would encourage you to check there. Perhaps you will need to create a technical user with sufficient roles to access the data you need.
Also the REST API Explorer which is found in SN Navigator can be of help to quickly test your table queries.
Hope that helps a bit!
In general table api returns all the columns associated to the table unless until if you have specified the specific column list in sysparam_fields, can you please try in post man or try the same api call from rest api explorer in Servicenow to understand the behavior. H

KeyCloak and Spring Security, how to restrict data partially

I have the following use case:
Users have general roles like:
devteam
this will give them access to several functions in the backend.
But additionally they also have a non-fix set of roles which may be added during time. Something like
devteam-europe (composite role to devteam role)
devteam-asia (composite role to devteam role)
etc.
Now I want the backend functions to behave like this:
Access function if role is "devteam": that works :)
But in the underlying sql queries I want to restrict the resultset depending on other roles. So devteam-europe will get other results as devteam-asia.
The big problem is, that in my applicaton each team has a uuid, while in KeyCloak the role has a speaking name. So I need to map somehow
devteam-europe to my internal UUID!
I could add attributes or properties to the role in KeyCloak, but they don't seem to be available in the JWT.
In my real world project it's a multi-tenancy applicatio with various entities.
Do you have any ideas, on how to to accomplish this?
Cheers Maik
I could add attributes or properties to the role in KeyCloak, but they don't seem to be available in the JWT.
In the corresponding client, you must define a Token Mapper which will tell Keycloak what source (in your case attribute or property) will map to which target (key => value) in your JWT.

Resources