Typically we do not use the application/asset owners as almost all of them are not interested in anything held in IGL, only their own application. We have a couple however, who are interested, but we do not want to give them full Manage capability on the application object in IGL.
Is it possible to adjust the permissions to be read only (i.e. View)? Or would we have to use a custom user attribute and custom permissioning?
Hi Andy, yes sure you can do that. You would need to create a customer Security Context file for that. For more info, you can reference the Help page on your system using the following link:
https://<hostname>:<port>/aveksa/help/Launch_Help.htm#Administrators/Managing__Application_Pr.htm
Could you let me know which owner positions you would like to downgrade privilege to what so I could give you a Security Context file to test with?
Application business owner or technical owner would be the obvious ones, but these are privileges granted automatically and dynamically by IGL via the default security context. I was under the impression that a custom SecurityContext file, which we already use, is only relevant for creating NEW custom privileges, not overriding existing default privileges?
For example (taken from the default security file) ...
SECURE_OBJECT_TYPE,NAME,ACTION,IMPLICIT_HAS_QUERY,IMPLICIT_BS_CHANGE,IMPLICIT_BU_CHANGE,SCOPE_TABLE,SCOPE_FILTER
Application,Business Owner,Manage,,scope,,t_applications,business_owner=${id} and resource_type='A' and is_deleted='FALSE'
Application,Technical Owner,Edit,,scope,,t_applications,technical_owner=${id} and resource_type='A' and is_deleted='FALSE'
Sorry Andy, must have missed your previous comment notification. Actually you can either add new stuff or overwrite existing stuff in the SecurityContext.csv. Basically using the same whole line as in the default Security Context, but just modifying the action will overwrite the default granted permissions.
For example this will downgrade the default positions to View only:
SECURE_OBJECT_TYPE,NAME,ACTION,IMPLICIT_HAS_QUERY,IMPLICIT_BS_CHANGE,IMPLICIT_BU_CHANGE,SCOPE_TABLE,SCOPE_FILTER
Application,Business Owner,View,,scope,,t_applications,business_owner=${id} and resource_type='A' and is_deleted='FALSE'
Application,Technical Owner,View,,scope,,t_applications,technical_owner=${id} and resource_type='A' and is_deleted='FALSE'
Ahah. Cool. I thought I'd seen elsewhere on here someone saying it didn't and if you wanted to you had to go edit the base SecurityContext file ... which could only be done in the deployed directory, which got replaced every time you restarted the application.
Will try it out.
I do have one followup question though, if you're able to answer that too !
The reason for doing this is so that we can extend access to the application owners to be able to view "their" applications in IGL, along with details of the access available (entitlements) AND access held (user-entitlements). The change to BusinessOwner privilege (above) would support this for most applications, however ...
We have several applications now configured to collect groups/group members from AD via an ADC, BUT link the group membership to AD accounts collected separately. This means that if you look at the application you see the groups as entitlements under What Access but don't see the users who are members of those groups under Who Has Access (because the accounts don't belong to the application). So how can we let the application owners view the users with access in their application?
One thought I had was to (somehow) grant dynamic access to the Groups page to the application owner, constrained on groups belonging to the relevant application. Does that work? Can you think of a better option?
Actually you do not need to (must not) edit the base SecurityContext.csv file inside the aveksa.ear. You just create another SecurityContext.csv file that only has your new/updated linesm and upload it from Admin > User Interface > Files > Security. No restart needed afterwards, just wait for the Aveksa ADC/EDC collections to finish as they will start automatically upon upload.
I believe your suggestion would work. I believe you want to grant Application owners view access to the Groups collected by their applications from the Users > Groups page.
Try appending these two Secuirty Context lines as well:
SECURE_OBJECT_TYPE,NAME,ACTION,IMPLICIT_HAS_QUERY,IMPLICIT_BS_CHANGE,IMPLICIT_BU_CHANGE,SCOPE_TABLE,SCOPE_FILTER
Group,Application Business Owner,View,scope,,,t_groups,application_id in (select id from t_applications where business_owner=${id} and resource_type='A' and is_deleted='FALSE')
Group,Application Technical Owner,View,scope,,,t_groups,application_id in (select id from t_applications where technical_owner=${id} and resource_type='A' and is_deleted='FALSE')
Jubbly. Works a treat - thanks Mostafa Helmy.
Thinking about it we could further extend that kind of access to allow application owners to run certain reports and only include data for "their" application(s) in the reports.
For reports, it's a little different. You can create dynamic reports using the :CurrentUserID runtime variable. This would allow you to create reports that give different outputs based on who is actually running them.
Check this KB for reference:
The SecurityContext could be used here to dynamically give "Run" access to those reports to certain people (for example: Application Owners )
Mostafa Helmy - I am now confused (and apologies for revisiting this topic). I realised I had only "updated" Business Owner and Technical Owner but not the Backups. So I went back into our custom SecurityContext.csv file, added the new lines for Backup Business Owner and Backup Technical Owner and uploaded the file.
I then added a couple of users to a test application and logged in as them to verify the access.
For the Backup Business Owner the user could access the application and everything was locked down.
For the Backup Technical Owner the user could access the application but could edit everything.
I then checked the Business Owner and Technical Owner ... and they had update access as well (Manage or Edit). Strange. I double-checked the custom SecurityContext file and all looked good. I even got hold of both that and the supplied files from the server and compared the relevant lines - only difference was View instead of Manage/Edit.
I even checked their Aveksa entitlement details on the user's access page. On selected the Info popup and expanding the Security Scope it correctly identified the application in question but stated "This entitlement gives Manage access to these objects." (or Edit).
As I said - I am confused. I thought I had checked that back in November but don't see what could have changed in the meantime. Any thoughts? ideas?
Sorry Andy, must have missed your previous comment notification. Actually you can either add new stuff or overwrite existing stuff in the SecurityContext.csv. Basically using the same whole line as in the default Security Context, but just modifying the action will overwrite the default granted permissions.
For example this will downgrade the default positions to View only:
SECURE_OBJECT_TYPE,NAME,ACTION,IMPLICIT_HAS_QUERY,IMPLICIT_BS_CHANGE,IMPLICIT_BU_CHANGE,SCOPE_TABLE,SCOPE_FILTER
Application,Business Owner,View,,scope,,t_applications,business_owner=${id} and resource_type='A' and is_deleted='FALSE'
Application,Technical Owner,View,,scope,,t_applications,technical_owner=${id} and resource_type='A' and is_deleted='FALSE'