Syncope as provisioning engine between identity providers and service providers

[Geert]

Hi list members,

Currently I'm looking into using Syncope as a provisioning engine
between identity providers and service providers.
Syncope as it is could already fulfil the parts regarding storage/
caching of identities and the provisioning towards service providers.
However, the part that seems to be missing, is a connection towards/
from identity providers, that would feed Syncope with identities.

In short, my question is: would such a use of Syncope fit into the
ideas the developers of Syncope have in mind?


To elaborate further, the goal we have is to lift the burden from many
identity providers (IdP) to all provision identities to a common set
of service providers. They should only have to setup a path to Syncope
once, letting Syncope do provisioning to specific service providers.
The IdP's should remain the primary source of identities (ie. not
consolidating into Syncope)

The roles Syncope could fulfil in this scenario are the following:
Allow IdP's to submit an initial set of their identities, as well as
subsequent changes.
Provide interfaces with different protocols for IdP's (plain LDAP, AD,
SPML, WS, REST)
Provide a means to separate identities from different IdP's

Connection between IdP and Syncope could be either push or pull,
depending on the protocol and the (security) requirements and
environment etc. Both batches and single entities could be supported.
Triggering provisioning (Syncope calls it propagating, right?) might
need some more thought as it is not as simple as just an update by a
user in the web UI anymore.


Could the identity connector framework be used for the connection
between IdP's and Syncope? Or is the interface of the connectors only
tailored for provisioning services?

An optional path for getting this functionality would be to use a
different channel to feed the underlying database with identities,
leaving Syncope untouched. But integrating on the database level does
not sound as a viable solution to me, for such generic components.

What do you think about this?

Kind regards,

Geert

[Fabio Martelli]

Hi Geert,
please, find my comments inline.

> Hi list members,
>
> Currently I'm looking into using Syncope as a provisioning engine
> between identity providers and service providers.
> Syncope as it is could already fulfil the parts regarding storage/
> caching of identities and the provisioning towards service providers.
> However, the part that seems to be missing, is a connection towards/
> from identity providers, that would feed Syncope with identities.
>
> In short, my question is: would such a use of Syncope fit into the
> ideas the developers of Syncope have in mind?

Yes it would. One of the principal uses of an IdM is that.
Syncope takes care of identity management and of the distribution/propagation of data on target resources (SP/IdP in your case).
Identities can be created using syncope console or a custom REST client or loaded from one or more authoritative resources.

> To elaborate further, the goal we have is to lift the burden from many
> identity providers (IdP) to all provision identities to a common set
> of service providers. They should only have to setup a path to Syncope
> once, letting Syncope do provisioning to specific service providers.
> The IdP's should remain the primary source of identities (ie. not
> consolidating into Syncope)

> The roles Syncope could fulfil in this scenario are the following:
> Allow IdP's to submit an initial set of their identities, as well as
> subsequent changes.
> Provide interfaces with different protocols for IdP's (plain LDAP, AD,
> SPML, WS, REST)
> Provide a means to separate identities from different IdP's
>
> Connection between IdP and Syncope could be either push or pull,
> depending on the protocol and the (security) requirements and
> environment etc. Both batches and single entities could be supported.
> Triggering provisioning (Syncope calls it propagating, right?) might
> need some more thought as it is not as simple as just an update by a
> user in the web UI anymore.

So you are saying that:
1. IdPs are authoritative resources
* Syncope can load identities from IdPs using connectors
- synchronization features under testing;
- official release including synchronization feature in december;
- pre-release of the synchronization feature is available in Syncope 0.7-EA
* IdPs can manage identities using syncope REST interface
2. SPs are target resources
* Syncope can propagate identities information towards SPs using identity connectors
3. identities distribution should be based on such kind of policies.
* Propagation towards SPs could be based on roles/resource assignment
* At the moment it is not possible to choose role/resource assignment at runtime (based on attribute value, for example)
* Role/resources must be specified at configuration time
4. Connection between IdP and Syncope could be push or poll:
* IdP can communicate with Syncope using REST interface only
* Syncope could communicate with IdPs using the identity connectors
5. must be possible to load more than one identity per request
* unfortunately using REST interface is only possible to create a user per request
* in a polling scenario, using identity connectors, can be loaded a set of one or more identities per request

> Could the identity connector framework be used for the connection
> between IdP's and Syncope? Or is the interface of the connectors only
> tailored for provisioning services?

Identity connectors can be used to load identities from an authoritative resources (just in polling mode)

> An optional path for getting this functionality would be to use a
> different channel to feed the underlying database with identities,
> leaving Syncope untouched. But integrating on the database level does
> not sound as a viable solution to me, for such generic components.
>
> What do you think about this?

Do you mean to configure Syncope in order to read and write data from and to databases managed by IdPs and SPs?
This is a possible solution, not so ugly.
Otherwise, in such case, you have to write your own Connid connector. In this case I'd like to ask you to submit your implementation to the community.

Regards,
F.

[Geert van der Ploeg]

Hi Fabio, others,

Thanks for clarifying the current state of the features I was looking for.
You reformulated my 'requirements' correctly.
As I understand now, 'synchronization' is the term you use for having
identities loaded from external authorities (IdP's), right?

You state:

> Identity connectors can be used to load identities from an authoritative resources (just in polling mode)

With "can be used" do you mean that using the existing connectors will
indeed be supported by Syncope? Or do you mean it's a possible
extension but not planned yet?

With my last suggestion, to use the database as an integration layer,
I meant to use Syncope for provisioning (propagating) but not using
the REST api nor the synchronization functionality for feeding the
persistence store of identities (but instead feeding the database by
an new, to be built, component)
But as I understand now, synchronization is the feature I was looking
for, so this whole database-integration-option is not relevant
anymore.

As for submitting contributions to Syncope to the community: If an
when I will be adding things to Syncope I will indeed submit them.

Regards,

Geert

[Fabio Martelli]

> Hi Fabio, others,
>
> Thanks for clarifying the current state of the features I was looking for.
> You reformulated my 'requirements' correctly.
> As I understand now, 'synchronization' is the term you use for having
> identities loaded from external authorities (IdP's), right?

Not exactly.
Synchronization is used to synchronize Syncope with a target resource.
A synchronization task can be executed once to load identities but can also be scheduled to perform synchronization.

> You state:
>> Identity connectors can be used to load identities from an authoritative resources (just in polling mode)
>
> With "can be used" do you mean that using the existing connectors will
> indeed be supported by Syncope? Or do you mean it's a possible
> extension but not planned yet?

Since Syncope 0.7-EA synchronization tasks are supported (also for an identities pre-load).
Of course, a target resource and its connector must support/implement a synchronization mechanism.

> With my last suggestion, to use the database as an integration layer,
> I meant to use Syncope for provisioning (propagating) but not using
> the REST api nor the synchronization functionality for feeding the
> persistence store of identities (but instead feeding the database by
> an new, to be built, component)
> But as I understand now, synchronization is the feature I was looking
> for, so this whole database-integration-option is not relevant
> anymore.

I think so.

>
> As for submitting contributions to Syncope to the community: If an
> when I will be adding things to Syncope I will indeed submit them.

Great! Thank you.

Regards,
F.

[Geert]

Hi Fabio, others,

> So you are saying that:
> 1. IdPs are authoritative resources
>         * Syncope can load identities from IdPs using connectors
>                 - synchronization features under testing;
>                 - official release including synchronization feature in december;
>                 - pre-release of the synchronization feature is available in Syncope 0.7-EA
>         * IdPs can manage identities using syncope REST interface

Let's assume I would configure two (or more) resources as identity
providers (resources that have synchronization capabilities), and thus
effectively import the users from these resources into Syncope.
How can I keep the users from these resources separate, for being able
to provision them to different target resources?
For example:
users from IdP 'internal employees AD directory' should be provisioned
to target resource 'corporate mail system' and to target resource 'svn
user database'
users from IdP 'contractors directory' should be provisioned to only
target resource 'svn user database'

And to take this one step further: ideally I would like to see
specific users from synchronized resource to be able to use the
console (using roles+entitlements?) to manage which target resources
their users (from only their synchronized resource) will be
provisioned to.

Is this wat Syncope is targeting?

I suppose I could create some attributes in the user schema to
determine what resource users are coming from, but at first glance
that looks a bit too brittle to me.

> 2. SPs are target resources
>         * Syncope can propagate identities information towards SPs using identity connectors
> 3. identities distribution should be based on such kind of policies.
>         * Propagation towards SPs could be based on roles/resource assignment
>         * At the moment it is not possible to choose role/resource assignment at runtime (based on attribute value, for example)
>         * Role/resources must be specified at configuration time

If I understand it correctly, roles can be used as an abstraction
between users and resources, to define in an abstract way which users
will be provisioned on which resources (e.g.: all users with role
'Accountant' will be provisioned on resource 'Our payroll system')

What do you mean by specifying role/resources at config time? The Role
modal page in the console offers a resource tab to maintain relations,
right?

Do you think roles are sufficient as the abstraction between users/
resources (also with regard to the synchronization discussion above)
or do you alreay have some future extension for this in mind?

Regards,

Geert

[Fabio Martelli]

Hi Geert,

> Hi Fabio, others,
>
>> So you are saying that:
>> 1. IdPs are authoritative resources
>> * Syncope can load identities from IdPs using connectors
>> - synchronization features under testing;
>> - official release including synchronization feature in december;
>> - pre-release of the synchronization feature is available in Syncope 0.7-EA
>> * IdPs can manage identities using syncope REST interface
>
> Let's assume I would configure two (or more) resources as identity
> providers (resources that have synchronization capabilities), and thus
> effectively import the users from these resources into Syncope.
> How can I keep the users from these resources separate, for being able
> to provision them to different target resources?
> For example:
> users from IdP 'internal employees AD directory' should be provisioned
> to target resource 'corporate mail system' and to target resource 'svn
> user database'
> users from IdP 'contractors directory' should be provisioned to only
> target resource 'svn user database'

If you want to provision all the users loaded from a certain IdP to one or more specified SP you can configure your synchronization tasks specifying default resources or default roles (of course, before this, you have to configure roles and resources in order to propagate identities on the right target resources).

> And to take this one step further: ideally I would like to see
> specific users from synchronized resource to be able to use the
> console (using roles+entitlements?) to manage which target resources
> their users (from only their synchronized resource) will be
> provisioned to.

Unfortunately, at the moment the roles+entitlements granularity doesn't permit to specify users able to manage just a single role.

> Is this wat Syncope is targeting?

Entitlements will be improved in the next future.

> I suppose I could create some attributes in the user schema to
> determine what resource users are coming from, but at first glance
> that looks a bit too brittle to me.

All the users loaded from a certain resource will be automatically associated to this resource.
You don't need to specify where users coming from: synchronization is automatically aware about this.

>> 2. SPs are target resources
>> * Syncope can propagate identities information towards SPs using identity connectors
>> 3. identities distribution should be based on such kind of policies.
>> * Propagation towards SPs could be based on roles/resource assignment
>> * At the moment it is not possible to choose role/resource assignment at runtime (based on attribute value, for example)
>> * Role/resources must be specified at configuration time
>
> If I understand it correctly, roles can be used as an abstraction
> between users and resources, to define in an abstract way which users
> will be provisioned on which resources (e.g.: all users with role
> 'Accountant' will be provisioned on resource 'Our payroll system')
>
> What do you mean by specifying role/resources at config time? The Role
> modal page in the console offers a resource tab to maintain relations,
> right?

Yes, it's right.
I suggest these few following steps:
1. configure connectors (for IdPs and SPs)
2. configure resources for each connector
3. configure roles and associate resource to roles
4. configure your synchronization tasks (without cron information if you want to execute the task just for the first load)
5. specify for each sync task a set of one or more default roles in order to provision SP resources associated to these roles
6. execute your sync task in order to load users

> Do you think roles are sufficient as the abstraction between users/
> resources (also with regard to the synchronization discussion above)
> or do you alreay have some future extension for this in mind?

We do think that roles are sufficient as abstraction between users/resources.
Furthermore, the possibility to organize roles in a hierarchy and to inherit attributes from father role, make this abstraction sufficient to describe whatever kind of organization.

Regards,
F.

[Francesco Chicchiriccò]

On 24/08/2011 08:19, Fabio Martelli wrote:
> [..]

>> And to take this one step further: ideally I would like to see specific users from synchronized resource to be able to use the console (using roles+entitlements?) to manage which target resources their users (from only their synchronized resource) will be provisioned to.
> Unfortunately, at the moment the roles+entitlements granularity doesn't permit to specify users able to manage just a single role.

Hi all,
just to say that the authorization model (including entitlements and
roles) is waiting to be properly documented, as per [2]: for the moment,
the only available (draft and incomplete) information is at [1].

Regards.

[1] https://groups.google.com/group/syncope-dev/msg/19588b9302eab8e4
[2] https://code.google.com/p/syncope/issues/detail?id=113

--
Francesco Chicchiricc�

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

[Geert]

Thank you both Fabio and Francesco, for giving some more insight into
the authorization / permissions model.

regards,
Geert

On Aug 24, 9:07 am, Francesco Chicchiriccò <chicchiri...@gmail.com>
wrote: