sumitmf
New Member.
254 views

Accounts/Permissions driven by LDAP groups.

Hi,
We have use case where accounts and permissions are not coming to us from application. Permissions are defined as LDAP groups. All the people in the group will have permissions named as LDAP group.
For example A-LADAP-ADMIN group will have "A-LDAP-ADMIN" permission. These groups are not stored anywhere in the database. Since the accounts and permissions are not coming form the application , we cannot compare these to the identities and permissions in eDirectory. What is the best approach to implement this use case.

Thanks.
0 Likes
5 Replies
Micro Focus Expert
Micro Focus Expert

Re: Accounts/Permissions driven by LDAP groups.

On 4/24/19 10:04 AM, sumitmf wrote:
>
> Hi,
> We have use case where accounts and permissions are not coming to us
> from application. Permissions are defined as LDAP groups. All the people
> in the group will have permissions named as LDAP group.
> For example A-LADAP-ADMIN group will have "A-LDAP-ADMIN" permission.
> These groups are not stored anywhere in the database. Since the accounts
> and permissions are not coming form the application , we cannot compare
> these to the identities and permissions in eDirectory. What is the best
> approach to implement this use case.
>
> Thanks.
>
>

Greetings,
In reviewing what you have outlined, it is a bit confusing and
contradicting.

1) Permission are always going to come from an application. Be that an
an actual application for which ID Gov can connect to via specific
collector (for example AD) or via JDBC. Or, that application could be a
csv file that represents the application.

2) The best practice pattern (except for the IDM Permission Collector)
is that in your Application Source you have:
(a) Account Collector
(b) Permission Collector

The "flow" is Permission -> Account (as the holder) -> Identity

In the above you would have some attribute on the Account that would map
to your Identity. When this is possible that makes it a "mapped"
account. When there can not be a match then it results in an "unmapped
account"

One can then create and run reviews for Accounts and unmapped accounts.


Unfortunately, what you have provided is not enough to provide guidance.
I would suggest opening a Service Request so that we can talk to
discuss the actual use case and how best to move forward.

--
Sincerely,
Steven Williams
Principal Enterprise Architect
Micro Focus
0 Likes
Micro Focus Expert
Micro Focus Expert

Re: Accounts/Permissions driven by LDAP groups.

On 4/24/19 11:47 AM, Steven Williams wrote:
> On 4/24/19 10:04 AM, sumitmf wrote:
>>
>> Hi,
>> We have use case where accounts and permissions are not coming to us
>> from application. Permissions are defined as LDAP groups. All the people
>> in the group will have permissions named as LDAP group.
>> For example A-LADAP-ADMIN group will have "A-LDAP-ADMIN" permission.
>> These groups are not stored anywhere in the database. Since the accounts
>> and permissions are not coming form the application , we cannot compare
>> these to the identities and permissions in eDirectory. What is the best
>> approach to implement this use case.
>>
>> Thanks.
>>
>>

> Greetings,
>    In reviewing what you have outlined, it is a bit confusing and
> contradicting.
>
> 1) Permission are always going to come from an application.  Be that an
> an actual application for which ID Gov can connect to via specific
> collector (for example AD) or via JDBC.  Or, that application could be a
> csv file that represents the application.
>
> 2) The best practice pattern (except for the IDM Permission Collector)
> is that in your Application Source you have:
> (a) Account Collector
> (b) Permission Collector
>
> The "flow" is Permission -> Account (as the holder) -> Identity
>
> In the above you would have some attribute on the Account that would map
> to your Identity.  When this is possible that makes it a "mapped"
> account.  When there can not be a match then it results in an "unmapped
> account"
>
> One can then create and run reviews for Accounts and unmapped accounts.
>
>
> Unfortunately, what you have provided is not enough to provide guidance.
>  I would suggest opening a Service Request so that we can talk to
> discuss the actual use case and how best to move forward.
>

Greetings,

If you are saying:

A) My Identity Source is eDirectory

B) I will have groups in eDirecotry or Active Directory that represent
"permission). For example the Group named A-LADAP-ADMIN


Then, you would utilize the eDirectory or Active Directory permission
collector. By default they are set to look at groups as permissions.


Please see my note earlier about also having the Account Collector
within this Application source.

If the above does not answer your original question then please open a
Service Request so we can talk.


--
Sincerely,
Steven Williams
Principal Enterprise Architect
Micro Focus
0 Likes
sumitmf
New Member.

Re: Accounts/Permissions driven by LDAP groups.

Thanks Steve. Correct , Identity source is eDirectory where these LDAP groups reside. We are not getting any data account/permission from application as this is not stored in their database. They just verbally give us the name of the LDAP groups which are basically permissions and contain people having this permission. As you mentioned , we used eDirectory account/permission collectors but in this case basically we are getting our account/permission data from eDirectory rather than application so we can not compare data between our eDirectory and the data actually used by application. We can not generate a report showing difference between eDirectory and application data (account/permission)
0 Likes
Micro Focus Expert
Micro Focus Expert

Re: Accounts/Permissions driven by LDAP groups.

On 4/24/19 3:24 PM, sumitmf wrote:
>
> Thanks Steve. Correct , Identity source is eDirectory where these LDAP
> groups reside. We are not getting any data account/permission from
> application as this is not stored in their database. They just verbally
> give us the name of the LDAP groups which are basically permissions and
> contain people having this permission. As you mentioned , we used
> eDirectory account/permission collectors but in this case basically we
> are getting our account/permission data from eDirectory rather than
> application so we can not compare data between our eDirectory and the
> data actually used by application. We can not generate a report showing
> difference between eDirectory and application data (account/permission)
>
>

Greetings,

"
account/permission data from eDirectory rather than
application so we can not compare data between our eDirectory and the
data actually used by application
"

The above statement is outside of the scope of ID Gov so I do not see
how or why it matters in this product.



In the case that was outlined, the groups in eDirectory will represent
the "real" permissions in application "x". So, all that one can do is
collect this data from eDirectory and then review it.


If there is not an IDM diver that is updating the membership between
application "X" and these groups in eDirectory (and vice versa) then it
will require a manual process. Which is also outside of the scope of ID
Gov.


--
Sincerely,
Steven Williams
Principal Enterprise Architect
Micro Focus
0 Likes
Knowledge Partner
Knowledge Partner

Re: Accounts/Permissions driven by LDAP groups.

On 4/24/2019 12:00 PM, Steven Williams wrote:
> On 4/24/19 11:47 AM, Steven Williams wrote:
>> On 4/24/19 10:04 AM, sumitmf wrote:
>>>
>>> Hi,
>>> We have use case where accounts and permissions are not coming to us
>>> from application. Permissions are defined as LDAP groups. All the people
>>> in the group will have permissions named as LDAP group.
>>> For example A-LADAP-ADMIN group will have "A-LDAP-ADMIN" permission.
>>> These groups are not stored anywhere in the database. Since the accounts
>>> and permissions are not coming form the application , we cannot compare
>>> these to the identities and permissions in eDirectory. What is the best
>>> approach to implement this use case.
>>>
>>> Thanks.
>>>
>>>

>> Greetings,
>>     In reviewing what you have outlined, it is a bit confusing and
>> contradicting.
>>
>> 1) Permission are always going to come from an application.  Be that
>> an an actual application for which ID Gov can connect to via specific
>> collector (for example AD) or via JDBC.  Or, that application could be
>> a csv file that represents the application.
>>
>> 2) The best practice pattern (except for the IDM Permission Collector)
>> is that in your Application Source you have:
>> (a) Account Collector
>> (b) Permission Collector
>>
>> The "flow" is Permission -> Account (as the holder) -> Identity
>>
>> In the above you would have some attribute on the Account that would
>> map to your Identity.  When this is possible that makes it a "mapped"
>> account.  When there can not be a match then it results in an
>> "unmapped account"
>>
>> One can then create and run reviews for Accounts and unmapped accounts.
>>
>>
>> Unfortunately, what you have provided is not enough to provide
>> guidance.   I would suggest opening a Service Request so that we can
>> talk to discuss the actual use case and how best to move forward.
>>

> Greetings,
>
> If you are saying:
>
> A) My Identity Source is eDirectory
>
> B) I will have groups in eDirecotry or Active Directory that represent
> "permission).  For example the Group named A-LADAP-ADMIN
>
>
> Then, you would utilize the eDirectory or Active Directory permission
> collector.  By default they are set to look at groups as permissions.
>
>
> Please see my note earlier about also having the Account Collector
> within this Application source.
>
> If the above does not answer your original question then please open a
> Service Request so we can talk.


I wonder if he is trying to describe an abstraction.

The App relies on LDAP groups for permissioning. He is collecting from
LDAP (Unclear if AD or eDir). But teh app itself cannot be directly
collected. Which makes me think the way to handle it is to collect the
LDAP groups (eDir or AD) and manage those, knowing in your
docs/processes/head that these flow through to map to the App permissions.



0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.