[jira] [Commented] (SYNCOPE-308) When trying to update an user in status 'rejected', an error 500 is returned

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SYNCOPE-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13575969#comment-13575969
 ] 

Hudson commented on SYNCOPE-308:


Integrated in Syncope-1_0_X #136 (See 
[https://builds.apache.org/job/Syncope-1_0_X/136/])
[SYNCOPE-308] Re-merging user workflow definition from trunk (Revision 
1444867)

 Result = SUCCESS
ilgrosso : 
Files : 
* /syncope/branches/1_0_X/core/src/main/resources/userWorkflow.bpmn20.xml


> When trying to update an user in status 'rejected', an error 500 is returned
> 
>
> Key: SYNCOPE-308
> URL: https://issues.apache.org/jira/browse/SYNCOPE-308
> Project: Syncope
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.0.5, 1.1.0
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Fix For: 1.0.6, 1.1.0
>
>
> This happens with the default workflow definition. How to reproduce from the 
> admin console:
>  1. as admin, create an user with role 9
>  2. under TODO, claim approval
>  3. reject
>  4. try to edit such user under Users
> The problem here is that 500 is returned; the expected result is instead that 
> the response is delegated to the underlying workflow definition.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (SYNCOPE-308) When trying to update an user in status 'rejected', an error 500 is returned

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SYNCOPE-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13575963#comment-13575963
 ] 

Hudson commented on SYNCOPE-308:


Integrated in Syncope-trunk #85 (See 
[https://builds.apache.org/job/Syncope-trunk/85/])
[SYNCOPE-308] Merge from 1_0_X (Revision 1444864)

 Result = SUCCESS
ilgrosso : 
Files : 
* /syncope/trunk
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/workflow/user/activiti/ActivitiUserWorkflowAdapter.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/workflow/user/activiti/task/Delete.java
* /syncope/trunk/core/src/main/resources/userWorkflow.bpmn20.xml


> When trying to update an user in status 'rejected', an error 500 is returned
> 
>
> Key: SYNCOPE-308
> URL: https://issues.apache.org/jira/browse/SYNCOPE-308
> Project: Syncope
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.0.5, 1.1.0
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Fix For: 1.0.6, 1.1.0
>
>
> This happens with the default workflow definition. How to reproduce from the 
> admin console:
>  1. as admin, create an user with role 9
>  2. under TODO, claim approval
>  3. reject
>  4. try to edit such user under Users
> The problem here is that 500 is returned; the expected result is instead that 
> the response is delegated to the underlying workflow definition.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (SYNCOPE-308) When trying to update an user in status 'rejected', an error 500 is returned

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SYNCOPE-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13575907#comment-13575907
 ] 

Hudson commented on SYNCOPE-308:


Integrated in Syncope-1_0_X #135 (See 
[https://builds.apache.org/job/Syncope-1_0_X/135/])
[SYNCOPE-308] Default workflow changed to raise exception when update of 
rejected user is attempted (Revision 1444850)

 Result = SUCCESS
ilgrosso : 
Files : 
* 
/syncope/branches/1_0_X/console/src/main/resources/org/apache/syncope/console/pages/Users.html
* 
/syncope/branches/1_0_X/core/src/main/java/org/apache/syncope/core/workflow/ActivitiUserWorkflowAdapter.java
* 
/syncope/branches/1_0_X/core/src/main/java/org/apache/syncope/core/workflow/activiti/Delete.java
* /syncope/branches/1_0_X/core/src/main/resources/userWorkflow.bpmn20.xml


> When trying to update an user in status 'rejected', an error 500 is returned
> 
>
> Key: SYNCOPE-308
> URL: https://issues.apache.org/jira/browse/SYNCOPE-308
> Project: Syncope
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.0.5, 1.1.0
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Fix For: 1.0.6, 1.1.0
>
>
> This happens with the default workflow definition. How to reproduce from the 
> admin console:
>  1. as admin, create an user with role 9
>  2. under TODO, claim approval
>  3. reject
>  4. try to edit such user under Users
> The problem here is that 500 is returned; the expected result is instead that 
> the response is delegated to the underlying workflow definition.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (SYNCOPE-308) When trying to update an user in status 'rejected', an error 500 is returned

[JIRA]

 [ 
https://issues.apache.org/jira/browse/SYNCOPE-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francesco Chicchiriccò resolved SYNCOPE-308.


Resolution: Fixed

1_0_X
  http://svn.apache.org/r1444850
  http://svn.apache.org/r1444867

trunk
  http://svn.apache.org/r1444864

> When trying to update an user in status 'rejected', an error 500 is returned
> 
>
> Key: SYNCOPE-308
> URL: https://issues.apache.org/jira/browse/SYNCOPE-308
> Project: Syncope
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.0.5, 1.1.0
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Fix For: 1.0.6, 1.1.0
>
>
> This happens with the default workflow definition. How to reproduce from the 
> admin console:
>  1. as admin, create an user with role 9
>  2. under TODO, claim approval
>  3. reject
>  4. try to edit such user under Users
> The problem here is that 500 is returned; the expected result is instead that 
> the response is delegated to the underlying workflow definition.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Synchronizing Roles

[Colm O hEigeartaigh]

Hi Francesco,

We can of course, file an improvement on the framework [1] and then on
> every connector, then wait for the implementation but it would take
> quite a while. Moreover, this make SYNCOPE-139 (Support OpenICF connector
> bundles) harder because we will be making a non retro-compatible change.
>
> Moreover, I also think we can assume that anyone that wants to work with a
> specific connector is supposed to take a look at its documentation [2],
> which includes supported object classes.


Thanks for looking into this, I agree with your conclusions.

Colm.

On Mon, Feb 11, 2013 at 1:09 PM, Francesco Chicchiriccò  wrote:

> On 08/02/2013 18:11, Francesco Chicchiriccň wrote:
>
>> On 08/02/2013 17:55, Colm O hEigeartaigh wrote:
>>
>>> The basic idea is that for propagating / synchronizing users you need a
 ConnId connector supporting ObjectClass.ACCOUNT (all available connector
 bundles) while for propagating / synchronizing roles you need a ConnId
 connector supporting ObjectClass.GROUP (only the LDAP connector bundle,
 currently).

>>> Thanks for the explanation Francesco! I'll turn my attention to
>>> experimenting with an LDAP backend so. What do you think about a JIRA to
>>> query the underlying Connector to see whether it supports
>>> ObjectClass.GROUP, and to disable the ability to add Role Mappings in the
>>> Resource if it does not?
>>>
>>
>> I am not sure whether ConnId provides a framework operation to check if a
>> given ObjectClass is supported nor to list the supported object classes,
>> hence I think a sort of guess should be put in place. But disabling some
>> console component because of such guess would be an hazard...
>>
>> I will investigate next week to see if this check is feasible (and
>> reliable).
>>
>
> Colm,
> the result of my investigation is that the ConnId framework does not
> provide any method for querying a connector for supported object classes.
>
> We can of course, file an improvement on the framework [1] and then on
> every connector, then wait for the implementation but it would take
> quite a while. Moreover, this make SYNCOPE-139 (Support OpenICF connector
> bundles) harder because we will be making a non retro-compatible change.
>
> Moreover, I also think we can assume that anyone that wants to work with a
> specific connector is supposed to take a look at its documentation [2],
> which includes supported object classes.
>
> WDYT?
>
> [1] 
> https://connid.atlassian.net/**browse/BASE
> [2] https://connid.atlassian.net/**wiki/display/BASE/Available+**
> Connector+Bundles
>
>  On Fri, Feb 8, 2013 at 4:18 PM, Francesco Chicchiriccň
>>> wrote:
>>>
>>>  On 08/02/2013 17:10, Colm O hEigeartaigh wrote:

  Hi all,
>
> I'm experimenting with synchronizing roles into Syncope on trunk.
>
> Firstly, what is the difference between a User mapping in a Resource
> where
> you select "ROLE" as the entity, and the Role Mapping tab where you can
> only select "ROLE"?
>
>  When you add a mapping item for users with ROLE entities, you are
 propagating the value(s) of a role attribute as part of the user data.
 Here
 you are managing an user (i.e. ObjectClass.ACCOUNT for ConnId).

 When you add a mapping item for roles (only ROLE entities allowed), you
 are propagating the role data. Here you are managing a role (i.e.
 ObjectClass.GROUP for ConnId).


   Let's say I have a database table with a Username, Password, some

> attributes, and a Role name. I want to import this Role into Syncope
> and
> also see that the User has this Role when I edit the User in the
> Console.
> Is this possible?
>
>  The basic idea is that for propagating / synchronizing users you need
 a
 ConnId connector supporting ObjectClass.ACCOUNT (all available connector
 bundle) while for propagating / synchronizing roles you need a ConnId
 connector supporting ObjectClass.GROUP (only the LDAP connector bundle,
 currently).

 Moreover, the use case you report above is for propagating memberships
 (i.e. the fact that a user belongs to a role), not the role itself.
 Propagating memberships is not supported by the ConnId framework;
 however,
 I've developed some simple actions for achieving this goal, at least for
 LDAP as part of SYNCOPE-26.

 Hope this clarifies a bit.

 Regards.

>>>
>>  --
> Francesco Chicchiriccň
>
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~**ilgrosso/
>
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: Password encoding query

[Francesco Chicchiriccò]

On 11/02/2013 14:45, Colm O hEigeartaigh wrote:

Hi Francesco,


do you mean opening another improvement issue, besides SYNCOPE-164, for 
synchronizing non-cleartext passwords?

Yes. I see them as separate use-cases. This task is to synchronize
(non-cleartext) passwords into Syncope, passthrough authentication is to
delegate user authentication to the backend resource. Do you agree with
this distinction?


Yes, completely.


I agree with this but I don't see it as particularly straightforward:
consider for example that we cannot refer to any specific connector bundle
from inside the SyncopeSyncResultHandler, hence we should find the cleanest
place to encapsulate the following logic:

Yep, good point.


Regards.


On Mon, Feb 11, 2013 at 1:17 PM, Francesco Chicchiriccò 
wrote:
On 11/02/2013 13:30, Colm O hEigeartaigh wrote:


Hi Francesco,

  This should be instead: "The ability to synchronize non-cleartext

passwords from external resources sounds like a nice new feature, isn't it?"


Yes I think so. I think the passthrough authentication use-case is more
powerful, as I don't see an easy way to support (for example) salting
using
this approach. But it should be pretty straightforward to implement, just
treat the retrieved password as hashed according to an algorithm set on
the
Connector for the DB Connector, or via "{CIPHER}VALUE" for LDAP, etc.
Shall
I create a JIRA for this task?


Hi Colm,
do you mean opening another improvement issue, besides SYNCOPE-164, for
synchronizing non-cleartext passwords?

I agree with this but I don't see it as particularly straightforward:
consider for example that we cannot refer to any specific connector bundle
from inside the SyncopeSyncResultHandler, hence we should find the cleanest
place to encapsulate the following logic:

if (password.isClearText()) {
// do as currently done
} else {
   if (connector.isLDAP()) {
// extract cipher and value
   } else if (connector.isDBTable()) {
// treat value as ciphered with the cipher defined in connector
configuration
   } else {
 ...
   }
}

Regards.

  On Tue, Feb 5, 2013 at 2:02 PM, Francesco Chicchiriccò

wrote:

  On 05/02/2013 13:53, Francesco Chicchiriccň wrote:

  On 05/02/2013 12:48, Colm O hEigeartaigh wrote:

  Hi all,

Just thinking aloud here about how passwords are encoded in Syncope.
Let's
say I have some Users in an SQL backend I want to synchronize into
Syncope.
I want to 'retrieve passwords' in the Connector, as I want to allow
users
to call on the 'rest/user/verifyPassword/X.json?password=Y' API,
and

so I
provide an appropriate mapping.

  Currently this cannot work: the password value synchronizing from

external resource is currently just ignored - a new random
policy-compliant
password is generated (look at the end of ConnObjectUtil.
getAttributableTO()
- called by SyncopeSyncResultHandler.create()).

  Correction: as correctly pointed out by Colm, this happens only if no

password was provided by the synchronizing resource.


   If the passwords are stored in the backend in a hashed format then
there


is

no way of successfully calling the above API from what I can see. The
'Password Cipher Algorithm' String of the Connector only applies to the
hashing algorithm used for propagation not for synchronization.
PasswordEncoder.verify() will hash the user password according to
user.getCipherAlgorithm(), and so it will end up hashing the password
twice
in this use-case.

  Actually this use case, e.g. authenticating users against an external

resource, is covered by SYNCOPE-164 as "passthrough authentication".

   Does it make sense that if the Connector is configured to hash
passwords


on
the propagation side using a given algorithm, that we can have some
internal logic in Syncope that will treat a retrieved password as
hashed
according to this algorithm?

  Definitely yes: the way how the synchronizing password value is

interpreted could also depend on the connector: for example
{CIPHER}VALUE
for LDAP.

The ability to synchronize passwords from external resources sounds like
a nice new feature, isn't it?

  This should be instead: "The ability to synchronize non-cleartext

passwords from external resources sounds like a nice new feature, isn't
it?"

Regards.


--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/

Re: Password encoding query

[Colm O hEigeartaigh]

Hi Francesco,

do you mean opening another improvement issue, besides SYNCOPE-164, for
> synchronizing non-cleartext passwords?
>

Yes. I see them as separate use-cases. This task is to synchronize
(non-cleartext) passwords into Syncope, passthrough authentication is to
delegate user authentication to the backend resource. Do you agree with
this distinction?


>
> I agree with this but I don't see it as particularly straightforward:
> consider for example that we cannot refer to any specific connector bundle
> from inside the SyncopeSyncResultHandler, hence we should find the cleanest
> place to encapsulate the following logic:


Yep, good point.

Colm.

On Mon, Feb 11, 2013 at 1:17 PM, Francesco Chicchiriccò  wrote:

> On 11/02/2013 13:30, Colm O hEigeartaigh wrote:
>
>> Hi Francesco,
>>
>>  This should be instead: "The ability to synchronize non-cleartext
>>> passwords from external resources sounds like a nice new feature, isn't it?"
>>>
>> Yes I think so. I think the passthrough authentication use-case is more
>> powerful, as I don't see an easy way to support (for example) salting
>> using
>> this approach. But it should be pretty straightforward to implement, just
>> treat the retrieved password as hashed according to an algorithm set on
>> the
>> Connector for the DB Connector, or via "{CIPHER}VALUE" for LDAP, etc.
>> Shall
>> I create a JIRA for this task?
>>
>
> Hi Colm,
> do you mean opening another improvement issue, besides SYNCOPE-164, for
> synchronizing non-cleartext passwords?
>
> I agree with this but I don't see it as particularly straightforward:
> consider for example that we cannot refer to any specific connector bundle
> from inside the SyncopeSyncResultHandler, hence we should find the cleanest
> place to encapsulate the following logic:
>
> if (password.isClearText()) {
> // do as currently done
> } else {
>   if (connector.isLDAP()) {
>// extract cipher and value
>   } else if (connector.isDBTable()) {
>// treat value as ciphered with the cipher defined in connector
> configuration
>   } else {
> ...
>   }
> }
>
> Regards.
>
>  On Tue, Feb 5, 2013 at 2:02 PM, Francesco Chicchiriccò
>> wrote:
>>
>>  On 05/02/2013 13:53, Francesco Chicchiriccň wrote:
>>>
>>>  On 05/02/2013 12:48, Colm O hEigeartaigh wrote:

  Hi all,
>
> Just thinking aloud here about how passwords are encoded in Syncope.
> Let's
> say I have some Users in an SQL backend I want to synchronize into
> Syncope.
> I want to 'retrieve passwords' in the Connector, as I want to allow
> users
> to call on the 'rest/user/verifyPassword/X.json?password=Y' API,
> and
>
> so I
> provide an appropriate mapping.
>
>  Currently this cannot work: the password value synchronizing from
 external resource is currently just ignored - a new random
 policy-compliant
 password is generated (look at the end of ConnObjectUtil.
 getAttributableTO()
 - called by SyncopeSyncResultHandler.create()).

  Correction: as correctly pointed out by Colm, this happens only if no
>>> password was provided by the synchronizing resource.
>>>
>>>
>>>   If the passwords are stored in the backend in a hashed format then
>>> there
>>>
 is
> no way of successfully calling the above API from what I can see. The
> 'Password Cipher Algorithm' String of the Connector only applies to the
> hashing algorithm used for propagation not for synchronization.
> PasswordEncoder.verify() will hash the user password according to
> user.getCipherAlgorithm(), and so it will end up hashing the password
> twice
> in this use-case.
>
>  Actually this use case, e.g. authenticating users against an external
 resource, is covered by SYNCOPE-164 as "passthrough authentication".

   Does it make sense that if the Connector is configured to hash
 passwords

> on
> the propagation side using a given algorithm, that we can have some
> internal logic in Syncope that will treat a retrieved password as
> hashed
> according to this algorithm?
>
>  Definitely yes: the way how the synchronizing password value is
 interpreted could also depend on the connector: for example
 {CIPHER}VALUE
 for LDAP.

 The ability to synchronize passwords from external resources sounds like
 a nice new feature, isn't it?

  This should be instead: "The ability to synchronize non-cleartext
>>> passwords from external resources sounds like a nice new feature, isn't
>>> it?"
>>>
>>> Regards.
>>>
>>
> --
> Francesco Chicchiriccò
>
>
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~**ilgrosso/
>
>

[jira] [Assigned] (SYNCOPE-308) When trying to update an user in status 'rejected', an error 500 is returned

[JIRA]

 [ 
https://issues.apache.org/jira/browse/SYNCOPE-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francesco Chicchiriccò reassigned SYNCOPE-308:
--

Assignee: Francesco Chicchiriccò

> When trying to update an user in status 'rejected', an error 500 is returned
> 
>
> Key: SYNCOPE-308
> URL: https://issues.apache.org/jira/browse/SYNCOPE-308
> Project: Syncope
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.0.5, 1.1.0
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Fix For: 1.0.6, 1.1.0
>
>
> This happens with the default workflow definition. How to reproduce from the 
> admin console:
>  1. as admin, create an user with role 9
>  2. under TODO, claim approval
>  3. reject
>  4. try to edit such user under Users
> The problem here is that 500 is returned; the expected result is instead that 
> the response is delegated to the underlying workflow definition.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Password encoding query

[Francesco Chicchiriccò]

On 11/02/2013 13:30, Colm O hEigeartaigh wrote:

Hi Francesco,


This should be instead: "The ability to synchronize non-cleartext passwords from 
external resources sounds like a nice new feature, isn't it?"

Yes I think so. I think the passthrough authentication use-case is more
powerful, as I don't see an easy way to support (for example) salting using
this approach. But it should be pretty straightforward to implement, just
treat the retrieved password as hashed according to an algorithm set on the
Connector for the DB Connector, or via "{CIPHER}VALUE" for LDAP, etc. Shall
I create a JIRA for this task?


Hi Colm,
do you mean opening another improvement issue, besides SYNCOPE-164, for 
synchronizing non-cleartext passwords?


I agree with this but I don't see it as particularly straightforward: 
consider for example that we cannot refer to any specific connector 
bundle from inside the SyncopeSyncResultHandler, hence we should find 
the cleanest place to encapsulate the following logic:


if (password.isClearText()) {
// do as currently done
} else {
  if (connector.isLDAP()) {
   // extract cipher and value
  } else if (connector.isDBTable()) {
   // treat value as ciphered with the cipher defined in connector 
configuration

  } else {
...
  }
}

Regards.


On Tue, Feb 5, 2013 at 2:02 PM, Francesco Chicchiriccò
wrote:


On 05/02/2013 13:53, Francesco Chicchiriccň wrote:


On 05/02/2013 12:48, Colm O hEigeartaigh wrote:


Hi all,

Just thinking aloud here about how passwords are encoded in Syncope.
Let's
say I have some Users in an SQL backend I want to synchronize into
Syncope.
I want to 'retrieve passwords' in the Connector, as I want to allow users
to call on the 'rest/user/verifyPassword/X.**json?password=Y' API, and
so I
provide an appropriate mapping.


Currently this cannot work: the password value synchronizing from
external resource is currently just ignored - a new random policy-compliant
password is generated (look at the end of ConnObjectUtil.**getAttributableTO()
- called by SyncopeSyncResultHandler.**create()).


Correction: as correctly pointed out by Colm, this happens only if no
password was provided by the synchronizing resource.


  If the passwords are stored in the backend in a hashed format then there

is
no way of successfully calling the above API from what I can see. The
'Password Cipher Algorithm' String of the Connector only applies to the
hashing algorithm used for propagation not for synchronization.
PasswordEncoder.verify() will hash the user password according to
user.getCipherAlgorithm(), and so it will end up hashing the password
twice
in this use-case.


Actually this use case, e.g. authenticating users against an external
resource, is covered by SYNCOPE-164 as "passthrough authentication".

  Does it make sense that if the Connector is configured to hash passwords

on
the propagation side using a given algorithm, that we can have some
internal logic in Syncope that will treat a retrieved password as hashed
according to this algorithm?


Definitely yes: the way how the synchronizing password value is
interpreted could also depend on the connector: for example {CIPHER}VALUE
for LDAP.

The ability to synchronize passwords from external resources sounds like
a nice new feature, isn't it?


This should be instead: "The ability to synchronize non-cleartext
passwords from external resources sounds like a nice new feature, isn't it?"

Regards.


--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/

Re: Synchronizing Roles

[Francesco Chicchiriccò]

On 08/02/2013 18:11, Francesco Chicchiriccò wrote:

On 08/02/2013 17:55, Colm O hEigeartaigh wrote:
The basic idea is that for propagating / synchronizing users you 
need a ConnId connector supporting ObjectClass.ACCOUNT (all 
available connector bundles) while for propagating / synchronizing 
roles you need a ConnId connector supporting ObjectClass.GROUP (only 
the LDAP connector bundle, currently).

Thanks for the explanation Francesco! I'll turn my attention to
experimenting with an LDAP backend so. What do you think about a JIRA to
query the underlying Connector to see whether it supports
ObjectClass.GROUP, and to disable the ability to add Role Mappings in 
the

Resource if it does not?


I am not sure whether ConnId provides a framework operation to check 
if a given ObjectClass is supported nor to list the supported object 
classes, hence I think a sort of guess should be put in place. But 
disabling some console component because of such guess would be an 
hazard...


I will investigate next week to see if this check is feasible (and 
reliable).


Colm,
the result of my investigation is that the ConnId framework does not 
provide any method for querying a connector for supported object classes.


We can of course, file an improvement on the framework [1] and then on 
every connector, then wait for the implementation but it would take 
quite a while. Moreover, this make SYNCOPE-139 (Support OpenICF 
connector bundles) harder because we will be making a non 
retro-compatible change.


Moreover, I also think we can assume that anyone that wants to work with 
a specific connector is supposed to take a look at its documentation 
[2], which includes supported object classes.


WDYT?

[1] https://connid.atlassian.net/browse/BASE
[2] 
https://connid.atlassian.net/wiki/display/BASE/Available+Connector+Bundles



On Fri, Feb 8, 2013 at 4:18 PM, Francesco Chicchiriccò
wrote:


On 08/02/2013 17:10, Colm O hEigeartaigh wrote:


Hi all,

I'm experimenting with synchronizing roles into Syncope on trunk.

Firstly, what is the difference between a User mapping in a 
Resource where
you select "ROLE" as the entity, and the Role Mapping tab where you 
can

only select "ROLE"?


When you add a mapping item for users with ROLE entities, you are
propagating the value(s) of a role attribute as part of the user 
data. Here

you are managing an user (i.e. ObjectClass.ACCOUNT for ConnId).

When you add a mapping item for roles (only ROLE entities allowed), you
are propagating the role data. Here you are managing a role (i.e.
ObjectClass.GROUP for ConnId).


  Let's say I have a database table with a Username, Password, some
attributes, and a Role name. I want to import this Role into 
Syncope and
also see that the User has this Role when I edit the User in the 
Console.

Is this possible?


The basic idea is that for propagating / synchronizing users you need a
ConnId connector supporting ObjectClass.ACCOUNT (all available 
connector

bundle) while for propagating / synchronizing roles you need a ConnId
connector supporting ObjectClass.GROUP (only the LDAP connector bundle,
currently).

Moreover, the use case you report above is for propagating memberships
(i.e. the fact that a user belongs to a role), not the role itself.
Propagating memberships is not supported by the ConnId framework; 
however,
I've developed some simple actions for achieving this goal, at least 
for

LDAP as part of SYNCOPE-26.

Hope this clarifies a bit.

Regards.



--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/

Re: Password encoding query

[Colm O hEigeartaigh]

Hi Francesco,

This should be instead: "The ability to synchronize non-cleartext passwords
> from external resources sounds like a nice new feature, isn't it?"
>

Yes I think so. I think the passthrough authentication use-case is more
powerful, as I don't see an easy way to support (for example) salting using
this approach. But it should be pretty straightforward to implement, just
treat the retrieved password as hashed according to an algorithm set on the
Connector for the DB Connector, or via "{CIPHER}VALUE" for LDAP, etc. Shall
I create a JIRA for this task?

Colm.


On Tue, Feb 5, 2013 at 2:02 PM, Francesco Chicchiriccò
wrote:

> On 05/02/2013 13:53, Francesco Chicchiriccň wrote:
>
>> On 05/02/2013 12:48, Colm O hEigeartaigh wrote:
>>
>>> Hi all,
>>>
>>> Just thinking aloud here about how passwords are encoded in Syncope.
>>> Let's
>>> say I have some Users in an SQL backend I want to synchronize into
>>> Syncope.
>>> I want to 'retrieve passwords' in the Connector, as I want to allow users
>>> to call on the 'rest/user/verifyPassword/X.**json?password=Y' API, and
>>> so I
>>> provide an appropriate mapping.
>>>
>>
>> Currently this cannot work: the password value synchronizing from
>> external resource is currently just ignored - a new random policy-compliant
>> password is generated (look at the end of 
>> ConnObjectUtil.**getAttributableTO()
>> - called by SyncopeSyncResultHandler.**create()).
>>
>
> Correction: as correctly pointed out by Colm, this happens only if no
> password was provided by the synchronizing resource.
>
>
>  If the passwords are stored in the backend in a hashed format then there
>>> is
>>> no way of successfully calling the above API from what I can see. The
>>> 'Password Cipher Algorithm' String of the Connector only applies to the
>>> hashing algorithm used for propagation not for synchronization.
>>> PasswordEncoder.verify() will hash the user password according to
>>> user.getCipherAlgorithm(), and so it will end up hashing the password
>>> twice
>>> in this use-case.
>>>
>>
>> Actually this use case, e.g. authenticating users against an external
>> resource, is covered by SYNCOPE-164 as "passthrough authentication".
>>
>>  Does it make sense that if the Connector is configured to hash passwords
>>> on
>>> the propagation side using a given algorithm, that we can have some
>>> internal logic in Syncope that will treat a retrieved password as hashed
>>> according to this algorithm?
>>>
>>
>> Definitely yes: the way how the synchronizing password value is
>> interpreted could also depend on the connector: for example {CIPHER}VALUE
>> for LDAP.
>>
>> The ability to synchronize passwords from external resources sounds like
>> a nice new feature, isn't it?
>>
>
> This should be instead: "The ability to synchronize non-cleartext
> passwords from external resources sounds like a nice new feature, isn't it?"
>
> Regards.
>
> --
> Francesco Chicchiriccň
>
>
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~**ilgrosso/
>
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: Role propagation query

[Francesco Chicchiriccò]

On 11/02/2013 13:21, Colm O hEigeartaigh wrote:

Hi all,

I have an Apache DS backend + I can synchronize role (names) by adding a
Role Mapping in the Resource. The question is how can I propagate a new
role to the backend? It doesn't appear to be as straightforward as
synchronization, as I guess I need to define some value for the "member"
attribute. Propagation fails with:

java.lang.ArrayIndexOutOfBoundsException: 1
 at
org.connid.bundles.ldap.commons.GroupHelper.addMemberAttributeIfMissing(GroupHelper.java:171)
 at
org.connid.bundles.ldap.modify.LdapCreate.executeImpl(LdapCreate.java:120)


Hi Colm,
take a look at test configuration: the LDAP connector configuration + 
LDAP resource mapping (for users and roles) is working either in 
propagation and in synchronization (both with embedded ApacheDS).


Regards.

--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/

Role propagation query

[Colm O hEigeartaigh]

Hi all,

I have an Apache DS backend + I can synchronize role (names) by adding a
Role Mapping in the Resource. The question is how can I propagate a new
role to the backend? It doesn't appear to be as straightforward as
synchronization, as I guess I need to define some value for the "member"
attribute. Propagation fails with:

java.lang.ArrayIndexOutOfBoundsException: 1
at
org.connid.bundles.ldap.commons.GroupHelper.addMemberAttributeIfMissing(GroupHelper.java:171)
at
org.connid.bundles.ldap.modify.LdapCreate.executeImpl(LdapCreate.java:120)

Colm.


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

RE: [DISCUSS] JAXRS integration tests

[Andrei Shakirin]

Hi Francesco,

Option (1) is OK for me, 
would ask committers to take care of -Pjaxrs as well as selenium profile for 
console and post to mailing list in case of any problems regarding jaxrs 
integration tests.

Cheers,
Andrei.

> -Original Message-
> From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]
> Sent: Freitag, 8. Februar 2013 18:13
> To: dev@syncope.apache.org
> Subject: Re: [DISCUSS] JAXRS integration tests
> 
> On 08/02/2013 16:54, Andrei Shakirin wrote:
> > Hi,
> >
> > We have finally all JAX-RS integration tests green.
> > To minimize the risk of breaking JAX-RS interface by further 1.1.0
> changes/fixes, I would propose any of two ways:
> >
> > 1.   Just ask all committers to run -Pjaxrs profile before any 1.1.0 
> > commit
> >
> > 2.   Activate JAX-RS tests additionally to Spring MVC tests in 
> > integration
> build (that make build 3 min longer).
> >
> > Any thoughts?
> 
> Obvious consideration: (1) has less impact, (2) is safer.
> 
> Being a choice necessary, I'd think to put this on the same level of the
> selenium profile for console and go for (1).
> 
> Regards.
> 
> --
> Francesco Chicchiriccò
> 
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~ilgrosso/

[jira] [Commented] (SYNCOPE-215) ReadOnly option for virtual attributes

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SYNCOPE-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13575742#comment-13575742
 ] 

Hudson commented on SYNCOPE-215:


Integrated in Syncope-trunk #84 (See 
[https://builds.apache.org/job/Syncope-trunk/84/])
[SYNCOPE-215] Implement usage of AbstractVirSchema#isReadonly() + basci 
test (Revision 1444739)
[SYNCOPE-215] - Committing Fabio's modified patch (Revision 1444727)

 Result = SUCCESS
ilgrosso : 
Files : 
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/rest/data/AbstractAttributableDataBinder.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/rest/data/SchemaDataBinder.java
* 
/syncope/trunk/core/src/test/java/org/apache/syncope/core/persistence/dao/VirSchemaTest.java

coheigea : 
Files : 
* 
/syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/VirtualSchemaModalPage.java
* 
/syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/panels/VirtualAttributesPanel.java
* 
/syncope/trunk/console/src/main/resources/org/apache/syncope/console/pages/VirtualSchemaModalPage.html
* 
/syncope/trunk/console/src/main/resources/org/apache/syncope/console/pages/VirtualSchemaModalPage.properties
* 
/syncope/trunk/console/src/main/resources/org/apache/syncope/console/pages/VirtualSchemaModalPage_it.properties


> ReadOnly option for virtual attributes
> --
>
> Key: SYNCOPE-215
> URL: https://issues.apache.org/jira/browse/SYNCOPE-215
> Project: Syncope
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.0.1-incubating
> Environment: Tomcat 7, Microsoft 2008 Server with ActiveDirectory, 
> PostgreSQL 9.2.1
>Reporter: Jan Bernhardt
>Assignee: Colm O hEigeartaigh
> Fix For: 1.1.0
>
> Attachments: syncope-215-console.patch, syncope-215-console.patch
>
>
> There are situations when you can not change an attribute value of a remote 
> resource, since it is read only at the remote resource. To avoid exceptions 
> within syncope it would be important to set virtual attributes to read only 
> also.
> This would prevent administrators of changing an attribute that can not be 
> changed within the backend systems.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (SYNCOPE-215) ReadOnly option for virtual attributes

[Colm O hEigeartaigh (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SYNCOPE-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh resolved SYNCOPE-215.
-

Resolution: Fixed

> ReadOnly option for virtual attributes
> --
>
> Key: SYNCOPE-215
> URL: https://issues.apache.org/jira/browse/SYNCOPE-215
> Project: Syncope
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.0.1-incubating
> Environment: Tomcat 7, Microsoft 2008 Server with ActiveDirectory, 
> PostgreSQL 9.2.1
>Reporter: Jan Bernhardt
>Assignee: Colm O hEigeartaigh
> Fix For: 1.1.0
>
> Attachments: syncope-215-console.patch, syncope-215-console.patch
>
>
> There are situations when you can not change an attribute value of a remote 
> resource, since it is read only at the remote resource. To avoid exceptions 
> within syncope it would be important to set virtual attributes to read only 
> also.
> This would prevent administrators of changing an attribute that can not be 
> changed within the backend systems.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (SYNCOPE-215) ReadOnly option for virtual attributes

[Colm O hEigeartaigh (JIRA)]

[ 
https://issues.apache.org/jira/browse/SYNCOPE-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13575720#comment-13575720
 ] 

Colm O hEigeartaigh commented on SYNCOPE-215:
-


Thanks Fabio, that seems to work correctly. I have committed your modified 
patch.

Colm.

> ReadOnly option for virtual attributes
> --
>
> Key: SYNCOPE-215
> URL: https://issues.apache.org/jira/browse/SYNCOPE-215
> Project: Syncope
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.0.1-incubating
> Environment: Tomcat 7, Microsoft 2008 Server with ActiveDirectory, 
> PostgreSQL 9.2.1
>Reporter: Jan Bernhardt
>Assignee: Colm O hEigeartaigh
> Fix For: 1.1.0
>
> Attachments: syncope-215-console.patch, syncope-215-console.patch
>
>
> There are situations when you can not change an attribute value of a remote 
> resource, since it is read only at the remote resource. To avoid exceptions 
> within syncope it would be important to set virtual attributes to read only 
> also.
> This would prevent administrators of changing an attribute that can not be 
> changed within the backend systems.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira