[syncope-dev] Authorization/entitlements

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[syncope-dev] Authorization/entitlements

Geert van der Ploeg
Hi all,

I'd like to start a discussion about an extension to the entitlement
scheme of Syncope.

In short:
Currently Syncope authorizes for operations on types of entities based
on entitlements for these types. (e.g. Users with role 'manager' can
'create' all entities of type 'TargetResource').
This might be sufficient for certain uses. But I would like to see an
additional, orthogonal approach to this, that authorizes on subsets of
entities, based on a common owner, group, source system, or whatever.

Fabio Martelli stated in the syncope-users-list [1] that 'entitlements
will be improved'. Could this extension be included in the discussion
perhaps?

To elaborate:
An environment that has more than one source system of identities, it
might be necessary to keep these identities isolated, including the
roles these identities obtain in Syncope, the target resources they're
propagated to and the configuration for connectors.
Managing identities, resources, roles and connectors should then be
limited to those relating to each other.

I can come up with two approaches:
* a realm or namespace based approach
* a security-scheme-per-entity approach

The realm based approach lets realms (or namespaces/domains, whatever)
be defined in Syncope, and every entity in Syncope be linked to a
realm. Operations by an authenticated users are restricted to entities
of his own realm, as are propagation and synchronization tasks. From
the users perspective, the realm is the whole system.
Perhaps, realms could be nested to add some more flexibility.

The security-scheme-per-entity approach lets more fine grained
security schemes be defined. Every entity has its security scheme (can
be viewed,edited,executed by role x,y), with sensible defaults derived
from the authenticated user that creates the entity.

The realm based approach is light weight, coarse grained, strict, easy
to comprehend and non intrusive to users that don't need it.
The security scheme based approach is complex, flexible, and could
lead to configurations that are hard to understand/debug.

These are my first thoughts. But maybe someone is aware of an existing
approach/solution that could be plugged in or serve as inspiration,
instead of reinventing the wheel here?


With kind regards,

Geert

[1] http://groups.google.com/group/syncope-users/msg/df44a11c00287b9d
Reply | Threaded
Open this post in threaded view
|

Re: [syncope-dev] Authorization/entitlements

ilgrosso
Administrator
On 22/09/2011 16:20, Geert wrote:
> Hi all,
>
> I'd like to start a discussion about an extension to the entitlement scheme of Syncope.

Hi Geert (and sorry for late response).
Thank you for your thoughts: see my comments in-line.

> In short:
> Currently Syncope authorizes for operations on types of entities based on entitlements for these types. (e.g. Users with role 'manager' can 'create' all entities of type 'TargetResource').

Not completely correct: what said above is true for everything but users
(see [2]); specifically, user management entitlements (CREATE / READ /
UPDATE / DELETE / LIST) are considered alongside with what we call "role
management entitlements".
As reported in [2], "user A can create users under role 5 but not under
role 7, user B can update users under role 6 and 8, user C can update
role 8. This would imply, for example, that A needs to own USER_CREATE
and ROLE_5 entitlements (but not ROLE_7)"

> This might be sufficient for certain uses. But I would like to see an additional, orthogonal approach to this, that authorizes on subsets of entities, based on a common owner, group, source system, or whatever.

This sound interesting: if we find a viable way, we could think to
completely replace the current authorization mechanism with something
more general, including the "special" authorization processing for user
management as well.

> Fabio Martelli stated in the syncope-users-list [1] that 'entitlements will be improved'. Could this extension be included in the discussion perhaps?

Definitely: the only limit I can think of now, about this, would be
bound to time constraints: at the moment we are quite busy in some deep
changes and the list of tasks to be done before next planned release
(Ritornello [3]) is quite long [4].

Anyway, I don't see any problem if we think to include new authorization
mechanism in subsequent release (Soave [3]), expected for Q1 2012.

> To elaborate:
> An environment that has more than one source system of identities, it might be necessary to keep these identities isolated, including the roles these identities obtain in Syncope, the target resources they're propagated to and the configuration for connectors.
> Managing identities, resources, roles and connectors should then be limited to those relating to each other.
>
> I can come up with two approaches:
> * a realm or namespace based approach
> * a security-scheme-per-entity approach
>
> The realm based approach lets realms (or namespaces/domains, whatever) be defined in Syncope, and every entity in Syncope be linked to a realm. Operations by an authenticated users are restricted to entities of his own realm, as are propagation and synchronization tasks. From the users perspective, the realm is the whole system.
> Perhaps, realms could be nested to add some more flexibility.
>
> The security-scheme-per-entity approach lets more fine grained security schemes be defined. Every entity has its security scheme (can be viewed,edited,executed by role x,y), with sensible defaults derived from the authenticated user that creates the entity.
>
> The realm based approach is light weight, coarse grained, strict, easy to comprehend and non intrusive to users that don't need it.
> The security scheme based approach is complex, flexible, and could lead to configurations that are hard to understand/debug.
>
> These are my first thoughts. But maybe someone is aware of an existing approach/solution that could be plugged in or serve as inspiration, instead of reinventing the wheel here?

I would rather prefer the realm approach: even though
security-scheme-per-entity can appear more powerful at first, I agree
with you that configuring a even dumb security matrix would lead to
consistent headaches.

 From my past experience, I can think to an example per approach:
  * Hippo CMS repository [5]: here security issues are limited to who
can write / publish / approve a document, in which part of a document
repository; the web management interface really looks like a matrix [6]

  * OpenSSO (now OpenAM), an Open Source access manager first released
by Sun Microsystems, has an ubiquitous (nested) realm approach, with a
single pre-defined root realm. Each realm can define its own users,
groups, services, ... Parent realm can consider descendant realms' items
as own or not

Regards.

> [1] http://groups.google.com/group/syncope-users/msg/df44a11c00287b9d
[2] http://groups.google.com/group/syncope-dev/msg/19588b9302eab8e4
[3] http://wiki.syncope-idm.org/index.php?title=Roadmap
[4]
http://code.google.com/p/syncope/issues/list?can=2&q=label%3AMilestone-Release-201112
[5]
https://wiki.onehippo.com/display/CMS7/Repository+Authorization+and+Permissions
[6]
http://www.onehippo.org/binaries/content/gallery/images/screenshots/cms_M13/admins/set_permissions.png/set_permissions.png/hippogallery%3Apicture
[7] http://forgerock.com/openam.html

--
Francesco Chicchiriccò

"Computer Science is no more about computers than astronomy
is about telescopes." (E. W. Dijkstra)