• State Not Answered
  • Replies 6 replies
  • Subscribers 94 subscribers
  • Views 221 views
  • Users 0 members are here
Options
Related

[Web portal] Set the visibility of a new page based on having an AERole

fabio scarcella
1 month ago

I have created a new page on the web portal and I would like this menu to be visible only to users who own a specific AERole.
Is there an Angular component in the project that allows me to carry out this check?
Something like QerPermissionsService and QerPermissionsHelper which check on DialogGroups:

export function isPersonAdmin(groups: string[]): boolean {
  return groups.find(item => item.toUpperCase() === 'VI_4_PERSONADMIN') != null;
}

Any suggestion? Thanks in advance

  • 0 1 month ago

    Hi Fabio,

    Yes, that would be the starting point. At least I've done something like that for my GAP admin module using a program function , but almost the same applies to a permissions group/aerole

    • In qer-permissions-service.ts I've created a function:
    public async isGAPAdmin(): Promise<boolean> {
        return isGAPAdmin((await this.userService.getFeatures()).Features);
      }
    • In qer-permissions-helper.ts I've exported the function that checks the existence of the feature in the user list of features. But you can also use your function to find a specifc group or aerole.
    export function isGAPAdmin(features: string[]): boolean {
      return features.find((item) => item === 'Portal_UI_GAP') !=null;
    }
    • Then have a look, for instance, at the init.service.ts of the tsb module. It has a setupMenu() function that adds options to the different menus depending of the user roles. 

    Hth!

  • 0 1 month ago in reply to juancarlos camargo

    Thanks, Juan Carlos.

    I just want to add that the usage of a program function would be the recommended way of doing. This check is nearly free in comparison to a database query against an existing AERole membership. You can create your own custom program functions and assign them to the AERoles you would use for your membership check.

  • 0 1 month ago in reply to Markus Weiss-Ehlers

    Thank you guys for this discussion!

    Please excuse my stepping in, but I would like to broaden the scope here as some questions arised in my mind while reading this thread.

    First, I agree with Markus that binding access to features (QBMFeature) is very convenient and transparent. In our backend API we for example use request.Session.Principal.Features.IsAllowedAsync("specific_feature") to check, if the current Portal-User is allowed to use a specific endoint.

    So far this thread discussed checking the permissions in the UI. This is reasonable, because Portal-Users should see only what they are allowed to and the UI logic  could show/hide elements depending on that.

    But if the backend API isn't performing the same checks, a Portal-User could still call the API endpoint and obtain data which she shouldn't. Thus checking permissions in the UI only is not sufficient to effectively secure user access. 

    Hanno pointed out here v92 : GAP (Google accounts) API typedclient missing in web portal source code ? - Forum - Identity Manager Community - One Identity Community that one can create entries in DialogGroupHasAEDS to control access to API endpoints. This works nicely with custom API endoints, but not with vendor provided ones - some customizer logic prevents this.

    So the question is: how to secure standard (or vendor provided) API endpoints effectively with features / permissions groups? Any ideas?

    Thanks!

  • 0 1 month ago in reply to stanislav.stoytchev

    I shouldn't have read this xD

    When you say vendor provided endpoints, which do you mean?

    I know the thread you pointed out but I was so excited about my gap client working that I didnt pay much attention to these notes on the DialogGroupHasAEDS table. Apologies for this.

    Now, I've been making some tests with DialogGroupHasAEDS . I've created an entry for the endpoint get portal/canditates/Person and one of my permissions groups and it works as expected: If I'm not member of that permission group, I get the message "You dont have permissions to run this method". Amazing. 

    Well, to summarize. To access an api endpoint and , maybe, secure it you must be aware of:

    • Apiserver OS permissions: iis, firewall, network. The api server should only be accessible by the webservers.
    • There are permissions on the api method itself. Either oob or custom (via CCC.CompositionApi...). These calls can be authenticated, unauthenticated , via FixedCredentials in web,config etc...
    • Above that layer, there's this new one, that controls access to the api method once the user is authenticated.  
    • Custom Api keys and filters for object selection.
    • The UI itself.

    Am I wrong? Anything else that we should know? Because whenever I think I have a grip on this, there's a newer undocumented thing arising that knocks the whole thing down (joking) xD

  • 0 1 month ago in reply to juancarlos camargo

    By "vendor provided endpoints" I mean the oob ones. Sorry for the ambiguity...

    As of my current understanding your bullet points quite good summarize the whole security stack here. Not sure though if there is more... And yes, the UI is on top of all this, but relying solely on it for permissions checking is just security by obscurity Innocent