Sharing Permits and Prohibitions between GEODI and other applications

Application can send permits and prohibitions during the Feed process.

Using your own custom user, authorization role, or authorization definitions

Roles or definitions in the application's own authorization model can be submitted for permits and prohibitions. When a user makes a query, GEODI asks the other application for the user's authorizations. This process is repeated every 20 minutes. The other application must manage the user-role-authorization mappings by performing the Sharing user authorizations ( GEODI → APP) service.

// You can find all the features in the Feed API documentation
// Here you can see that roles 'Rol1','Rol2','Rol3' are permitted.
// Rol5 is denied.
{
	...
    Permission : {   Permit : ['Rol1','Rol2','Rol3'] , Deny : ['Rol5'] }
}

// You can find all the features in the Feed API documentation

{
	...
    Permission : {   Permit : ['UserID1','UserID2','UserID3'] , Deny : ['UserID5'] }
}

// You can find all the features in the Feed API documentation

{
	...
    Permission : {   Permit : ['DocID'] }
}

Using Group and User definitions recognized by GEODI

Groups and users recognized by GEODI can be used in Permit or Deny arrays.

• A Group ID must be used for GEODI Groups. A Group ID is an ID that used for identifying the Group in the Group list on the Geodi Authority management screen (the ID can be learned using the Inspect Element feature of browsers)  Example: UserGroup_111aa11-1b11-...
• User UniqueName should be used for GEODI users. Example: Geodi:guest
• LDAP SID should be used for LDAP Groups and users. Example:  S-1-5-......

// You can find all the features in the Feed API documentation
// Groups, LDAP Users and Geodi users that are included in Permit array are allowed
// Geodi:guest is not allowed
{
	...
    Permission : {   Permit : [' UserGroup_111aa11-1b11...','S-1-5-...','Geodi:ornek.kullanici'] , Deny : ['Geodi:guest'] }
}