[midPoint] roles, objects and permissions in midPoint

[Oleksandr Bodriagov (Polystar)]

Hi Radovan,

Thank you very much for your profound answer! As you say, MidPoint is so good at identity management that I mixed it up with an IAM server :)

Best regards,
Oleksandr


From: Radovan Semancik <radovan.semancik at evolveum.com<mailto:radovan.semancik at evolveum.com>>
Reply-To: midPoint General Discussion <midpoint at lists.evolveum.com<mailto:midpoint at lists.evolveum.com>>
Date: Monday 13 April 2015 08:41
To: "midpoint at lists.evolveum.com<mailto:midpoint at lists.evolveum.com>" <midpoint at lists.evolveum.com<mailto:midpoint at lists.evolveum.com>>
Subject: Re: [midPoint] roles, objects and permissions in midPoint

Hi,

The crucial issue here is that midPoint is not an authorization server. MidPoint is a provisioning system. Therefore the primary goal of roles in midPoint is to manage access control mechanisms in other system (e.g. LDAP groups, SAP roles, etc.) MidPoint is NOT designed to make access control decisions for other systems.

Side note: midPoint is not designed to make access control decisions for other systems. But it is designed to make access control decisions for its own data structures. And it does that well. Which perhaps caused this confusion. And this brings a simple answer to your first question: Object in midPoint is in fact any midPoint object (resource, role, org, user, etc.). But it has to be a midPoint object. It cannot be external object. It also does not make much sense for midPoint to act as an authorization server for other systems directly. Provisioning systems are quite complex and therefore they have performance limits. It is bast to keep provisioning systems to do what they does best: manage data. And let other systems to store, replicate and provide the data. E.g. directory servers.

If you want to make access control decisions for other systems that you need to add authorization server to your IAM solution (see https://wiki.evolveum.com/display/midPoint/Enterprise+Identity+Management). If your case is simple then any LDAP server could play this role. Just express the authorization statements in an LDAP attribute, e.g. in a form:

dn: uid=foo,ou=people,dc=example,dc=com
...
myAutz: server1:read:data
myAutz: server1:modify:report
myAutz: server2:read:report

In this simple case your applications can act as policy enforcement points. E.g. they will check the value of myAutz attribute and decide if the user is authorized or not. And midPoint can manage this attribute. E.g. there may be a midPoint role "Report administrator" that will set value "*:modify:report" to the myAutz attribute.

The LDAP directory will add performance and reliability to the solution. MidPoint will add manageability (e.g. who has permission to assign "Report administrator" role? and to whom? for how long? who has to approve?). This is the usual way IAM systems are built. Simple, but efficient.

If you need something more complex then your best chance is to look for a fully-blown authorization system and add that to the solution as well. E.g. Apache Fortress might be a good choice:
https://directory.apache.org/fortress/


--

                                           Radovan Semancik
                                          Software Architect
                                             evolveum.com



On 04/10/2015 04:37 PM, Oleksandr Bodriagov (Polystar) wrote:
Hi,

I have a question about roles, permissions, and objects in midPoint. According to NIST, "a role is essentially a collection of permissions", and permissions are relationships between operations and objects. MidPoint gives ability to define users, roles, and resources. It is not clear though how to define objects.

Our use case is as follows. We have a few RESTful web services to which we would like to control access using midpoint and our own access control server. Our permissions in this case would be something like:
  - read data from https://server1.com/whateever
  - modify report at https://server2.com/profile/whatever
  - read report at https://server2.com/profile/whatever

So, we have operations {read, modify, delete, ...} and objects {https://server1.com/whateever, https://server2.com/profile/whatever, ...}. We do not want midpoint to retrieve any information out of server1 or server2 whatsoever. Let's say that server1 and serever2 contain only financial information.  Our access control server receives a question if a user is allowed to perform some operation over some object. To answer this question the server should get user's permissions from midPoint using its REST API. We have setup a midPoint server with an embedded database. We have added users and roles, but we have no idea how to add our objects (simple URLs).  There is a notion of Resource in midPoint. It seems that resources are only used for propagation of users and roles from external databases or directories. Consequently, resource is not the same as RBAC object.

How should RBAC permission and objects be defined? Thank you in advance for your help.

Best regards,
Alex



_______________________________________________
midPoint mailing list
midPoint at lists.evolveum.com<mailto:midPoint at lists.evolveum.com>http://lists.evolveum.com/mailman/listinfo/midpoint


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20150416/628d5c50/attachment.htm>