PASOE - Programmatically access ACLs

we do indeed have something creative in a product called Secureable that we're developing and about to release.

Secureable is an authorization and secrets management system that plugs into PASOE and provides a single unified source for a number of different auth systems, like OIDC, JWT, LDAP. AD, Azure etc.  A user can be configured to have a number of auth sources , yet PASOE only needs to be configured once.

Secureable also can generate the OEABLSecurity.properties file, as well as the oeablSecurity.csv  file based on the groups and the roles that are applied to each group. For both Secureable and your PASOE application this installation this can be completely automated - which has a huge advantage when deploying your app.

This ACL list can be returned to a front end through a simple API call to secureable. We have an angular SDK for the front end and are about to complete the ABL SDK for PASOE.

Once you have authorized through Secureable, the PASOE session has a client-principal (CP) with the relevant user information available as properties, including the groups the user is a member of.

You can also store and access secrets based on the ACL . Secrets that are encrypted at rest and not visible or accessible to other users. So storing passwords / tokens / identity becomes a simple API call

Secureable can also generate single-use or time-restricted passwords for services like amazon , without the user having to know the admin or master passwords, or clientid / secretid

visit https://nodeable.io more information

> I’m not sure we want too much creativity in authorization … I think you should return what roles the current user has, after they're logged-in, and have the UI respond to that.  The UI knows what roles it can react to; the user knows which roles they have.  I'd think that's enough info to do the right thing in the UI.

The problem is that UI doesn't know what resources are available to what roles.  It's trivial to send the UI a list of the user's roles.  But at some point if you end up with hundreds of secured resources/tasks and dozens of roles, you don't want code in the front end with conditionals like "display this if the user has role xyz or abc or qrs".

I'm hoping for a single source of truth that can be maintained independently.

Thanks Julian.  I'd love to see a demo sometime.  Probably will come too late for my current project, but it would be nice to see what's available.

sure, we'll keep you in the loop,

Depending on how your apis are constructed, you could use the paths and the verbs to define the permissions for the front end.

For example if the csv dictates that

POST /users A,B,C

PUT /users/:id A,B,C

GET /users A,B,C,D

DELETE /users A

you can say to the front end that users in groups A,B,C have CREATE. UPDATE and READ permissions , only group D can DELETE users and group D have read-only permissions

As Tomcat can be configured to read files from anywhere on disk and serve them on a specific URL, create a url to return the csv file from the tomcat config folder to the client, which can parse the csv file and apply it to the front end routing.

If you're using angular, you can define the routes to be the same as the backend api , and add guards to check that the user has the right permissions to access that particular route 

You can create a generic service that takes the route in question (say delete) and be generic enough to be called from anywhere "userHasPermission("delete",'users")" to disable / remove the  "delete" button from the UI

Just my 2c: I would keep the roles pretty simple. For example api_user (or maybe a bit more specific crm_api_user, finance_api_user). When you log in to an IHybridRealm implementation you can assign the roles to a user. These roles can be used in oeablSecurity.csv to keep people out.

Now the nitty gritty auth can be done within 4GL: create a generic WebHandler and program in that WebHandler do the check against your user/resource auth matrix.

The advantage is that you don't have to "mess" with the PASOE config too much and it can be altered at runtime with immediate effect.

hth

And that's the crux of my question:  How can the UI know what groups can do what?  Code is not the place to contain that.  It has to somehow get the rules from the back end.

The UI may know that it needs to protect a certain button or API for example, but the UI should not be hard-coded as to what roles can access it.  It should call whatever the main source of truth is, and ask "can my current user run this button?" or "tell me what functions this user can run."

I think the answer to my question was that no, PASOE provides no built-in means for the oeablSecurity.csv file to be used by anything other than Spring's protection or URLs, so it's pretty much "roll your own".

> create a generic WebHandler and program in that WebHandler do the check against your user/resource auth matrix.

I think this is where we are heading.

- Higher level roles setup in oeablSecurity.csv

- Database contains lower-level roles and users to resource relationships.

- Webhandlers automatically enforce these

- Some API so the front end can also obtain the list of valid resources for the user from my own database.