You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@syncope.apache.org by Sergey Beryozkin <sb...@gmail.com> on 2015/04/28 15:33:28 UTC
[DISCUSS] Syncope as OAuth2 Server
Hi All,
Awhile back JB created a Syncope issue for Syncope to support OAuth2.
I'd like to continue the discussion about it and understand better what
can it mean for Syncope to become OAuth2-aware.
So Syncope is a generic user identity management system. It offers a
front-end to DB systems where the user information is stored and allows
a controlled access to this data.
OAuth2 is primarily about a resource owner allowing a controlled access
to a 3rd party client (web server, mobile, etc) to this owner's
account/data. OAuth2 can be big enough but ultimately is is
AuthorizationServer (for supporting redirection based flows) +
AccessTokenServer (for issuing tokens in exchange for grants) + some
generic/core token validation.
OAuth2 server requires storing the info about human users that have
logged in into OAuth2 Server and authorized a 3rd party clients. 3rd
party clients need to be registered so these registrations need to be
kept too. Transient code grants as well as access tokens and or refresh
tokens need to be linked to the 3rd party registrations, human user
logins, and also kept in DB. OAuth2 server that provides
AuthorizationServer will most likely need SSO supported.
I can think of several ways Syncope might support OAuth2.
One is where Syncope provides an authorized access to some of its
functionality. It is not clear how it would work because AFAIK Syncope
has no notion of user-specific Syncope accounts for managing user
identities specific to those accounts only.
Another option is where Syncope becomes a generic OAuth2 server,
orthogonally/in addition to its current functionality. Its current
functionality (user identity management) can be a part of OAuth2 server
itself. One option here is to use a generic CXF code to support it.
I'm not sure what would be the best option for Syncope (as far its road
map is concerned), and if Syncope should keep doing the identity
management only.
Comments are welcome.
Thanks, Sergey
Re: [DISCUSS] Syncope as OAuth2 Server
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 28/04/2015 17:00, Sergey Beryozkin wrote:
> Hi Francesco
>
> On 28/04/15 14:58, Francesco Chicchiriccò wrote:
>> On 28/04/2015 15:33, Sergey Beryozkin wrote:
>>> Hi All,
>>>
>>> Awhile back JB created a Syncope issue for Syncope to support OAuth2.
>>> I'd like to continue the discussion about it and understand better
>>> what can it mean for Syncope to become OAuth2-aware.
>>
>> Hi Sergey,
>> FYI, we're talking about SYNCOPE-534: I've added this thread there as
>> reference.
> Thanks...
>>
>>> So Syncope is a generic user identity management system. It offers a
>>> front-end to DB systems where the user information is stored and
>>> allows a controlled access to this data.
>>
>> Syncope is a provisioning engine, whose main responsibility is to keep
>> synchronized data across several identity repositories, relying on
>> different technologies: relational databases, LDAP, CSV, SOAP / REST
>> services, ...
>>
> I was suspecting I might not be describing Syncope correctly :-)
Eh eh eh, no problems at all, it's quite tricky, I know... :-)
>>> OAuth2 is primarily about a resource owner allowing a controlled
>>> access to a 3rd party client (web server, mobile, etc) to this owner's
>>> account/data. OAuth2 can be big enough but ultimately is is
>>> AuthorizationServer (for supporting redirection based flows) +
>>> AccessTokenServer (for issuing tokens in exchange for grants) + some
>>> generic/core token validation.
>>>
>>> OAuth2 server requires storing the info about human users that have
>>> logged in into OAuth2 Server and authorized a 3rd party clients. 3rd
>>> party clients need to be registered so these registrations need to be
>>> kept too. Transient code grants as well as access tokens and or
>>> refresh tokens need to be linked to the 3rd party registrations, human
>>> user logins, and also kept in DB. OAuth2 server that provides
>>> AuthorizationServer will most likely need SSO supported.
>>>
>>> I can think of several ways Syncope might support OAuth2.
>>>
>>> One is where Syncope provides an authorized access to some of its
>>> functionality. It is not clear how it would work because AFAIK Syncope
>>> has no notion of user-specific Syncope accounts for managing user
>>> identities specific to those accounts only.
>>>
>>> Another option is where Syncope becomes a generic OAuth2 server,
>>> orthogonally/in addition to its current functionality. Its current
>>> functionality (user identity management) can be a part of OAuth2
>>> server itself. One option here is to use a generic CXF code to support
>>> it.
>>>
>>> I'm not sure what would be the best option for Syncope (as far its
>>> road map is concerned), and if Syncope should keep doing the identity
>>> management only.
>>
>> As said above, Syncope is at the moment a provisioning engine, but its
>> roadmap [1] contains - for the late future, however, e.g. from 3.0.0
>> onwards - various authentication and access management features.
>>
>> Within this respect, embedding some OAuth2 features - e.g. the second
>> option above - looks as a nice addition.
>>
>> FYI I had some experience in building an OAuth2 server via CXF for
>> Olingo [2], and I've always thought that such approach could have been
>> used - with needed context modifications - with Syncope. WDYT?
>>
> Interesting, sure, that code shows a typical provider skeleton (FYI -
> it can become a bit simpler with respect to checking the
> approved/requested scopes - after the latest CXF update).
>
> If having an OAuth2 provider in Syncope will be about enhancing a
> provisioning aspect then may be it is option 1. I'm thinking of the
> 2nd option as about Syncope becoming a standalone OAuth2 server not
> strictly related to the provisioning aspect hence I was in doubt if it
> would be of interest to the team. May be both 1 and 2 options can be
> investigated in due time :-)
> I guess the discussion can continue whenever the team is ready to
> review SYNCOPE-534 :-)
Sure! SYNCOPE-534 is currently targeted to 2.0.0, so not very close but
not far as well.
Looking forward for having your support for this task!
Regards.
>> [1] https://cwiki.apache.org/confluence/display/SYNCOPE/Roadmap
>> [2]
>> https://github.com/apache/olingo-odata4/blob/master/fit/src/main/java/org/apache/olingo/fit/rest/OAuth2Provider.java
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC
http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Syncope as OAuth2 Server
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Francesco
On 28/04/15 14:58, Francesco Chicchiriccò wrote:
> On 28/04/2015 15:33, Sergey Beryozkin wrote:
>> Hi All,
>>
>> Awhile back JB created a Syncope issue for Syncope to support OAuth2.
>> I'd like to continue the discussion about it and understand better
>> what can it mean for Syncope to become OAuth2-aware.
>
> Hi Sergey,
> FYI, we're talking about SYNCOPE-534: I've added this thread there as
> reference.
Thanks...
>
>> So Syncope is a generic user identity management system. It offers a
>> front-end to DB systems where the user information is stored and
>> allows a controlled access to this data.
>
> Syncope is a provisioning engine, whose main responsibility is to keep
> synchronized data across several identity repositories, relying on
> different technologies: relational databases, LDAP, CSV, SOAP / REST
> services, ...
>
I was suspecting I might not be describing Syncope correctly :-)
>> OAuth2 is primarily about a resource owner allowing a controlled
>> access to a 3rd party client (web server, mobile, etc) to this owner's
>> account/data. OAuth2 can be big enough but ultimately is is
>> AuthorizationServer (for supporting redirection based flows) +
>> AccessTokenServer (for issuing tokens in exchange for grants) + some
>> generic/core token validation.
>>
>> OAuth2 server requires storing the info about human users that have
>> logged in into OAuth2 Server and authorized a 3rd party clients. 3rd
>> party clients need to be registered so these registrations need to be
>> kept too. Transient code grants as well as access tokens and or
>> refresh tokens need to be linked to the 3rd party registrations, human
>> user logins, and also kept in DB. OAuth2 server that provides
>> AuthorizationServer will most likely need SSO supported.
>>
>> I can think of several ways Syncope might support OAuth2.
>>
>> One is where Syncope provides an authorized access to some of its
>> functionality. It is not clear how it would work because AFAIK Syncope
>> has no notion of user-specific Syncope accounts for managing user
>> identities specific to those accounts only.
>>
>> Another option is where Syncope becomes a generic OAuth2 server,
>> orthogonally/in addition to its current functionality. Its current
>> functionality (user identity management) can be a part of OAuth2
>> server itself. One option here is to use a generic CXF code to support
>> it.
>>
>> I'm not sure what would be the best option for Syncope (as far its
>> road map is concerned), and if Syncope should keep doing the identity
>> management only.
>
> As said above, Syncope is at the moment a provisioning engine, but its
> roadmap [1] contains - for the late future, however, e.g. from 3.0.0
> onwards - various authentication and access management features.
>
> Within this respect, embedding some OAuth2 features - e.g. the second
> option above - looks as a nice addition.
>
> FYI I had some experience in building an OAuth2 server via CXF for
> Olingo [2], and I've always thought that such approach could have been
> used - with needed context modifications - with Syncope. WDYT?
>
Interesting, sure, that code shows a typical provider skeleton (FYI - it
can become a bit simpler with respect to checking the approved/requested
scopes - after the latest CXF update).
If having an OAuth2 provider in Syncope will be about enhancing a
provisioning aspect then may be it is option 1. I'm thinking of the 2nd
option as about Syncope becoming a standalone OAuth2 server not strictly
related to the provisioning aspect hence I was in doubt if it would be
of interest to the team. May be both 1 and 2 options can be investigated
in due time :-)
I guess the discussion can continue whenever the team is ready to review
SYNCOPE-537 :-)
Thanks, Sergey
> Regards.
>
> [1] https://cwiki.apache.org/confluence/display/SYNCOPE/Roadmap
> [2]
> https://github.com/apache/olingo-odata4/blob/master/fit/src/main/java/org/apache/olingo/fit/rest/OAuth2Provider.java
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: [DISCUSS] Syncope as OAuth2 Server
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 28/04/2015 15:33, Sergey Beryozkin wrote:
> Hi All,
>
> Awhile back JB created a Syncope issue for Syncope to support OAuth2.
> I'd like to continue the discussion about it and understand better
> what can it mean for Syncope to become OAuth2-aware.
Hi Sergey,
FYI, we're talking about SYNCOPE-534: I've added this thread there as
reference.
> So Syncope is a generic user identity management system. It offers a
> front-end to DB systems where the user information is stored and
> allows a controlled access to this data.
Syncope is a provisioning engine, whose main responsibility is to keep
synchronized data across several identity repositories, relying on
different technologies: relational databases, LDAP, CSV, SOAP / REST
services, ...
> OAuth2 is primarily about a resource owner allowing a controlled
> access to a 3rd party client (web server, mobile, etc) to this owner's
> account/data. OAuth2 can be big enough but ultimately is is
> AuthorizationServer (for supporting redirection based flows) +
> AccessTokenServer (for issuing tokens in exchange for grants) + some
> generic/core token validation.
>
> OAuth2 server requires storing the info about human users that have
> logged in into OAuth2 Server and authorized a 3rd party clients. 3rd
> party clients need to be registered so these registrations need to be
> kept too. Transient code grants as well as access tokens and or
> refresh tokens need to be linked to the 3rd party registrations, human
> user logins, and also kept in DB. OAuth2 server that provides
> AuthorizationServer will most likely need SSO supported.
>
> I can think of several ways Syncope might support OAuth2.
>
> One is where Syncope provides an authorized access to some of its
> functionality. It is not clear how it would work because AFAIK Syncope
> has no notion of user-specific Syncope accounts for managing user
> identities specific to those accounts only.
>
> Another option is where Syncope becomes a generic OAuth2 server,
> orthogonally/in addition to its current functionality. Its current
> functionality (user identity management) can be a part of OAuth2
> server itself. One option here is to use a generic CXF code to support
> it.
>
> I'm not sure what would be the best option for Syncope (as far its
> road map is concerned), and if Syncope should keep doing the identity
> management only.
As said above, Syncope is at the moment a provisioning engine, but its
roadmap [1] contains - for the late future, however, e.g. from 3.0.0
onwards - various authentication and access management features.
Within this respect, embedding some OAuth2 features - e.g. the second
option above - looks as a nice addition.
FYI I had some experience in building an OAuth2 server via CXF for
Olingo [2], and I've always thought that such approach could have been
used - with needed context modifications - with Syncope. WDYT?
Regards.
[1] https://cwiki.apache.org/confluence/display/SYNCOPE/Roadmap
[2]
https://github.com/apache/olingo-odata4/blob/master/fit/src/main/java/org/apache/olingo/fit/rest/OAuth2Provider.java
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC
http://people.apache.org/~ilgrosso/