Proprietary Application Permissions Collection (Homegrown Apps)

Proprietary applications can be commercial off-the-shelf applications or applications that an organization has developed in-house.

The Collector Synchronizer Service is the software component responsible for analyzing the permissions of a homegrown application.

To model, analyze, and collect the permissions for a homegrown application, File Access Manager must have information on the following data types.

Note: This information may include from where to bring this data type, its unique identifier, and other data type fields to query later:

• User – the list of all the Application’s Users

• Group – the list of all the Application’s Groups, and their parent-child nesting (if any)

• User-Group Relationships – which Group contain which Users (or which users are members in which group)

• Permission Types – all the possible permission types for the application (for example, Read, Write, Full Control)

• Business Resources – the list of all the Business Resources of the application, and the hierarchy parent-child relationships (if any) of the business resources

• Group-Permission Type-Business Resource Relationships – if the application allows granting permissions through Groups, File Access Manager must know which group provides which permission type on which business resource (for example, the Technical Write Group grants Full Control Permission on the Documents folder).

• User-Permission Type-Business Resource Relationships – if the application allows granting direct user permissions to business resources, File Access Manager needs to know which users are assigned which permission type on which business resource (for example, John has direct Full Control permission on the Documents folder).

The first step in defining a Permissions Collection for a homegrown application involves determining from where to bring the above information. First, define one or more Data Sources for each data type (using a simplified, single data source for all the data types above, as shown in the example below). The data source tables will be used to map various entities when the Permissions Collection process is defined later.

For example, it is possible to easily map a homegrown application that uses LDAP as the identity store and a RDBS database for the rest of the information by:

• Defining one or more data sources to bring the information on the Users, Groups, and User-Group relationships, and

• Defining another data source to collect the information on the business resources, permission types, and the user/group-permission type-business resource relationships

The table below lists sample permissions data in a single Data Source table.

User Name	Group Name	Permissions Type	Business Resource
Jonathan	Technical Writer	Full Control	Docs\Guides
John	Technical Writer	Full Control	Docs\Guides
Matt	Engineer	Full Control	R&D
Avi	QA	Read	R&D

The table below lists the distinct columns for each type of Data Source mapping. As the table shows, there are four distinct users, three distinct groups, two distinct Permission types, and two distinct business resources.

User	Group	Permission Type	Business Resource
Jonathan	Technical Writer	Full Control	Docs\Guides
John	Engineer	Read	Docs\Guides
Matt	QA		R&D
Avi

The example above shows a homegrown application that does not have direct user permissions, or nested groups, but does have its hierarchical business resources delimited by the ‘\’ char. The following example examines the relationships between data types.

Group	Members
Technical Writer	Jonathan, John
Engineer	Matt
QA	Avi

 

Group	Permission Type	Business Resource
Technical Writer	Full Control	Docs\Guides
Technical Writer	Full Control	Docs\Guides
Engineer	Read	R&D
QA	Read	R&D