PASOE - Programmatically access ACLs - Forum - OpenEdge Development - Progress Community

PASOE - Programmatically access ACLs

 Forum

PASOE - Programmatically access ACLs

This question is answered

Considering that PASOE uses the oeablSecurity.csv file to setup ACLs for various resources and verbs, I wonder if there is a way to access that programmatically from within the ABL?

Assuming there is an application with many resources and many groups, I would like to find a way to provide the front-end with a list of resources and verbs that the currently logged-in user can run, so that the front end can correctly display valid options for the user.

The only ways i can think of right now:

1. Have ABL code parse the oeablSecurity.csv file and use that to match up with the client principal object's groups to provide the list.

2. Don't use oeablSecurity.csv / Spring for securing resources, but instead have the webhandlers check some internal table at runtime.  Use that same table to tell the front end what can and can't be run.

I am not really fond of either answer, but I know I don't want the front end hard-coding what it displays based on what user groups could access what at design time.

I'm also not crazy about making the application's security dependent on a static CSV file that is tied more towards URL patterns in a particular order than actual back-end resources.

Has anyone done anything creative to solve these problems?

Verified Answer
  • 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

All Replies
  • 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 also not crazy about making the application's security dependent on a static CSV file that is tied more towards URL patterns in a particular order than actual back-end resources.

    There are use-cases for both URL-based and ABL-based authorization. I'd probably not remove the Spring-based authorisation since it's closer to the perimiter.
    The roles/rules may be provided by an authentication provider (like ldap), the resource server (the business logic code or db records or something else) or both.
     
    You can, in ABL, extract a user's roles from the asserted client-principal (ie those from the auth provider). The resource server roles will depend on the application and where they're stored.
     
     
    > I would like to find a way to provide the front-end with a list of resources and verbs that the currently logged-in user can run, so that the front end can correctly display valid options for the user.
     
    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.
     
    I thought there was more doc, but the KUIB follows this approach. There's some doc at community.progress.com/.../2939.how-to-implement-user-roles-in-kendo-ui-builder-2-1-with-an-openedge-backend .
     
     
     
     
     
     
     
  • > 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

  • > The problem is that UI doesn't know what resources are available to what roles. 
     
    It absolutely should. The screen widgets and/or their contents are the resources the UI is trying to procect. It does (should?) know what functionality it can and cannot provide, and also what its rules are for that.
     
    The UI should not be expected to know the whole gamut of all potential rules a user might have, and act accordingly.
     
     
     
  • 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.