[jira] [Updated] (SYNCOPE-138) Scripted SQL connector bundle

2013-02-14 Thread JIRA

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

Francesco Chicchiriccò updated SYNCOPE-138:
---

Fix Version/s: (was: 1.3.0)
   1.1.0

 Scripted SQL connector bundle
 -

 Key: SYNCOPE-138
 URL: https://issues.apache.org/jira/browse/SYNCOPE-138
 Project: Syncope
  Issue Type: New Feature
Reporter: Francesco Chicchiriccò
 Fix For: 1.1.0


 Provide a scripted SQL connector bundle.
 Probably connector instance configuration must be reviewed.
 Check whether OpenICF connector bundle [1] can be used.
 [1] http://openicf.forgerock.org/connectors/openicf-scriptedsql-connector/

--
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] [Assigned] (SYNCOPE-138) Scripted SQL connector bundle

2013-02-14 Thread JIRA

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

Francesco Chicchiriccò reassigned SYNCOPE-138:
--

Assignee: Marco Di Sabatino Di Diodoro

Besides code modifications that might be needed, please add a dedicated wiki 
page for how to do this.

 Scripted SQL connector bundle
 -

 Key: SYNCOPE-138
 URL: https://issues.apache.org/jira/browse/SYNCOPE-138
 Project: Syncope
  Issue Type: New Feature
Reporter: Francesco Chicchiriccò
Assignee: Marco Di Sabatino Di Diodoro
 Fix For: 1.1.0


 Provide a scripted SQL connector bundle.
 Probably connector instance configuration must be reviewed.
 Check whether OpenICF connector bundle [1] can be used.
 [1] http://openicf.forgerock.org/connectors/openicf-scriptedsql-connector/

--
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: Role propagation query

2013-02-14 Thread Colm O hEigeartaigh
Hi Francesco,

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).


I figured out the cause...it's due to a bug in the LDAP Connector bundle
when using groupOfNames:

https://connid.atlassian.net/browse/LDAP-5

Colm.

On Mon, Feb 11, 2013 at 12:23 PM, Francesco Chicchiriccò 
ilgro...@apache.org wrote:

 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/http://people.apache.org/~ilgrosso/




-- 
Colm O hEigeartaigh

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


[jira] [Resolved] (SYNCOPE-287) Information for release notes

2013-02-14 Thread Christian Schneider (JIRA)

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

Christian Schneider resolved SYNCOPE-287.
-

Resolution: Fixed

 Information for release notes
 -

 Key: SYNCOPE-287
 URL: https://issues.apache.org/jira/browse/SYNCOPE-287
 Project: Syncope
  Issue Type: Sub-task
  Components: documentation
Reporter: Francesco Chicchiriccò
Assignee: Christian Schneider
 Fix For: 1.1.0


 Release notes for 1.1.0 need to contain some description about the current 
 migration from Spring MVC to Apache CXF:
  * Spring MVC-based REST interface is still available but will be removed in 
 future releases
  * There is a migration guide available at...
  * Integration tests are still performed against Spring MVC

--
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-231) Using Standard JAX-RS API in Syncope (Introducing Apache CXF WS Stack)

2013-02-14 Thread Jan Bernhardt (JIRA)

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

Jan Bernhardt resolved SYNCOPE-231.
---

Resolution: Fixed

CXF is now fully functional integrated into CXF. All Integration-Test are 
successful.
Thanks to everyone participating with this issue.

 Using Standard JAX-RS API in Syncope (Introducing Apache CXF WS Stack)
 --

 Key: SYNCOPE-231
 URL: https://issues.apache.org/jira/browse/SYNCOPE-231
 Project: Syncope
  Issue Type: Improvement
  Components: console, core
Reporter: Jan Bernhardt
Assignee: Jan Bernhardt
 Fix For: 1.1.0

 Attachments: TaskService.patch


 Current REST Interfaces are based on Spring Webservice framework. 
 Goal of this task is to replace Spring with CXF and to relay on JAX-B and 
 JAX-RS annotations rather then Spring annotations.

--
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

2013-02-14 Thread Colm O hEigeartaigh
Here is the JIRA:

https://issues.apache.org/jira/browse/SYNCOPE-313

Colm.

On Mon, Feb 11, 2013 at 1:48 PM, Francesco Chicchiriccò ilgro...@apache.org
 wrote:

 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ò 
 ilgro...@apache.org

 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ò

 ilgro...@apache.orgwrote:

   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/http://people.apache.org/~ilgrosso/




-- 
Colm O hEigeartaigh

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


Re: Password encoding query

2013-02-14 Thread Francesco Chicchiriccò

On 14/02/2013 15:09, Colm O hEigeartaigh wrote:

Here is the JIRA:

https://issues.apache.org/jira/browse/SYNCOPE-313


Thanks: which fix version should we set for this? 1.2.0?
Roadmap [1] should be updated accordingly, then.

Regards.

[1] https://cwiki.apache.org/confluence/display/SYNCOPE/Roadmap

--
Francesco Chicchiriccò

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



[jira] [Commented] (SYNCOPE-307) Virtual Attributes don't propagated in case of update during synchronization

2013-02-14 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/SYNCOPE-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13578402#comment-13578402
 ] 

Hudson commented on SYNCOPE-307:


Integrated in Syncope-trunk #89 (See 
[https://builds.apache.org/job/Syncope-trunk/89/])
SYNCOPE-307: virtual attribute values must be retrieved before the 
propByRes purge - merged from branch 1_0_X (Revision 1446200)

 Result = SUCCESS
fmartelli : 
Files : 
* /syncope/trunk
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/propagation/impl/PropagationManager.java


 Virtual Attributes don't propagated in case of update during synchronization
 

 Key: SYNCOPE-307
 URL: https://issues.apache.org/jira/browse/SYNCOPE-307
 Project: Syncope
  Issue Type: Bug
  Components: core
Affects Versions: 1.0.6, 1.1.0
Reporter: fabio martelli
Assignee: fabio martelli
 Fix For: 1.0.6, 1.1.0


 UC:
 * Suppose two resources A and B;
 * Suppose to synchronize from A;
 * Suppose to have virtual attributes mapped just on B;
 * Suppose to retrieve a user to be updated locally and to be created new on B 
 (thanks to an ad-hoc user template).
 User will be updated locally and created on B but its virtual attribute 
 values won't be propagated on B.
 The bug is into the virtual attribute management during sync and propagation: 
 in the UC provided above, the 'populate' method of the class 
 AttributableOperations will never provide virtual attributes to be used by 
 SyncJob to create the update propagation task.

--
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-307) Virtual Attributes don't propagated in case of update during synchronization

2013-02-14 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/SYNCOPE-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13578407#comment-13578407
 ] 

Hudson commented on SYNCOPE-307:


Integrated in Syncope-1_0_X #141 (See 
[https://builds.apache.org/job/Syncope-1_0_X/141/])
SYNCOPE-307: virtual attribute values must be retrieved before the 
propByRes purge (Revision 1446195)

 Result = SUCCESS
fmartelli : 
Files : 
* 
/syncope/branches/1_0_X/core/src/main/java/org/apache/syncope/core/propagation/PropagationManager.java


 Virtual Attributes don't propagated in case of update during synchronization
 

 Key: SYNCOPE-307
 URL: https://issues.apache.org/jira/browse/SYNCOPE-307
 Project: Syncope
  Issue Type: Bug
  Components: core
Affects Versions: 1.0.6, 1.1.0
Reporter: fabio martelli
Assignee: fabio martelli
 Fix For: 1.0.6, 1.1.0


 UC:
 * Suppose two resources A and B;
 * Suppose to synchronize from A;
 * Suppose to have virtual attributes mapped just on B;
 * Suppose to retrieve a user to be updated locally and to be created new on B 
 (thanks to an ad-hoc user template).
 User will be updated locally and created on B but its virtual attribute 
 values won't be propagated on B.
 The bug is into the virtual attribute management during sync and propagation: 
 in the UC provided above, the 'populate' method of the class 
 AttributableOperations will never provide virtual attributes to be used by 
 SyncJob to create the update propagation task.

--
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: Role propagation query

2013-02-14 Thread Francesco Chicchiriccò

On 14/02/2013 14:56, Colm O hEigeartaigh wrote:

Hi Francesco,


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).


I figured out the cause...it's due to a bug in the LDAP Connector bundle
when using groupOfNames:

https://connid.atlassian.net/browse/LDAP-5


Nice catch (and fix)!

Regards.


On Mon, Feb 11, 2013 at 12:23 PM, Francesco Chicchiriccò 
ilgro...@apache.org wrote:

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/



[jira] [Created] (SYNCOPE-314) User list sort based on username fails

2013-02-14 Thread fabio martelli (JIRA)
fabio martelli created SYNCOPE-314:
--

 Summary: User list sort based on username fails 
 Key: SYNCOPE-314
 URL: https://issues.apache.org/jira/browse/SYNCOPE-314
 Project: Syncope
  Issue Type: Bug
  Components: console
Affects Versions: 1.0.6, 1.1.0
Reporter: fabio martelli
 Fix For: 1.0.6, 1.1.0


User list sort based on username fails

--
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] [Assigned] (SYNCOPE-314) User list sort based on username fails

2013-02-14 Thread fabio martelli (JIRA)

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

fabio martelli reassigned SYNCOPE-314:
--

Assignee: fabio martelli

 User list sort based on username fails 
 ---

 Key: SYNCOPE-314
 URL: https://issues.apache.org/jira/browse/SYNCOPE-314
 Project: Syncope
  Issue Type: Bug
  Components: console
Affects Versions: 1.0.6, 1.1.0
Reporter: fabio martelli
Assignee: fabio martelli
 Fix For: 1.0.6, 1.1.0


 User list sort based on username fails

--
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-314) User list sort based on username fails

2013-02-14 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/SYNCOPE-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13578603#comment-13578603
 ] 

Hudson commented on SYNCOPE-314:


Integrated in Syncope-1_0_X #143 (See 
[https://builds.apache.org/job/Syncope-1_0_X/143/])
SYNCOPE-314 fixed by extending inline properties (Revision 1446275)

 Result = UNSTABLE
fmartelli : 
Files : 
* 
/syncope/branches/1_0_X/console/src/main/java/org/apache/syncope/console/commons/SortableUserProviderComparator.java


 User list sort based on username fails 
 ---

 Key: SYNCOPE-314
 URL: https://issues.apache.org/jira/browse/SYNCOPE-314
 Project: Syncope
  Issue Type: Bug
  Components: console
Affects Versions: 1.0.6, 1.1.0
Reporter: fabio martelli
Assignee: fabio martelli
 Fix For: 1.0.6, 1.1.0


 User list sort based on username fails

--
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-314) User list sort based on username fails

2013-02-14 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/SYNCOPE-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13578617#comment-13578617
 ] 

Hudson commented on SYNCOPE-314:


Integrated in Syncope-trunk #91 (See 
[https://builds.apache.org/job/Syncope-trunk/91/])
SYNCOPE-314 merged from the branch 1_0_X - fixed (Revision 1446276)

 Result = UNSTABLE
fmartelli : 
Files : 
* /syncope/trunk
* 
/syncope/trunk/console/src/main/java/org/apache/syncope/console/commons/SortableAttributableProviderComparator.java


 User list sort based on username fails 
 ---

 Key: SYNCOPE-314
 URL: https://issues.apache.org/jira/browse/SYNCOPE-314
 Project: Syncope
  Issue Type: Bug
  Components: console
Affects Versions: 1.0.6, 1.1.0
Reporter: fabio martelli
Assignee: fabio martelli
 Fix For: 1.0.6, 1.1.0


 User list sort based on username fails

--
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


Syncope-trunk - Build # 91 - Unstable

2013-02-14 Thread Apache Jenkins Server
The Apache Jenkins build system has built Syncope-trunk (build #91)

Status: Unstable

Check console output at https://builds.apache.org/job/Syncope-trunk/91/ to view 
the results.

Syncope-1_0_X - Build # 144 - Fixed

2013-02-14 Thread Apache Jenkins Server
The Apache Jenkins build system has built Syncope-1_0_X (build #144)

Status: Fixed

Check console output at https://builds.apache.org/job/Syncope-1_0_X/144/ to 
view the results.