Re: Task "Rules"
Il 24/06/2014 12:24, Colm O hEigeartaigh ha scritto: Hi all, Hi Colm, What are the new task "rules" that have been added to trunk? When I create a new synchronization task with the default "Matching/Update" "Unmatching/Assign", it appears that the selected LDAPPasswordSyncActions class is not run. I created a new sync task with LDAPPasswordSyncActions class assigned and default Matching/Unmatching rules, very similar to LDAP Sync Task. Then I ran this test task and, debugging, I noticed that after() method of LDAPPasswordSyncActions class is ever executed (create, update); beforeCreate() method instead, when creating new user/role instance on Syncope, is never used due to the fact that SyncopeSyncResultHandler never calls: protected List create(final SyncDelta delta, final AttributableUtil attrUtil, final boolean dryRun). that calls beforeCreate() for each sync action available. So I think that class LDAPPasswordSyncActions is run, and there's another problem. But maybe I'm missing something, I'll investigate deeper today. Colm. Best Regards, Andrea -- Dott. Andrea Patricelli Tel +393204524292 Junior Engineer @ Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +390859116307 / FAX +39 085973 http://www.tirasa.net
R: Running Syncope Embed using a permanent h2 instance
Hi Francesco, thanks for your answer. As you suggested I've changed core/src/test/resources/persistence.properties but I still can't set H2 basedir outside workdir. In core.log I get this exception: org.h2.jdbc.JdbcSQLException: IO Exception: outside /apache-tomcat-7.0.53/work/Catalina/localhost/syncope-build-tools After some investigation I saw that build-tools project use a second instance of H2 and in the class H2StartStopListener it sets the H2 baseDir to work dir. I'm not an expert of H2 but it seems baseDir it's a system property that affects all instances. What's the best way to do you suggest to set basedir for syncope db outside work ? Thanks, Denis. -Messaggio originale- Da: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Inviato: martedì 24 giugno 2014 15:35 A: dev@syncope.apache.org Oggetto: Re: Running Syncope Embed using a permanent h2 instance On 24/06/2014 15:27, Denis Signoretto wrote: > Hi, > I've checked out Syncope 1_1_X to do some tests. I've seen that Syncope h2 db > it's created within target directory. > Everytime I launch mvn -P debug, target dir it's deleted. This means you are directly running from the actual Syncope sources: I'd suggest you instead to generate your own project from SNAPSHOT archetype [1] and then run in embedded mode [2] via mvn -P embedded. > I'm wondering if is there a way to launch Syncope embed mode/debug profile > using a permanent h2 location. > I've tried adding a customized persistence.properties file in > syncope-console\src\resources specifying both absolute and relative path > outside target dir but it seems workdir it's needed. > > Is there a better way to do it or get the same result ? You can proceed similar to the standalone distribution [3]: only, you need to change core/src/test/resources/persistence.properties not core/src/main/resources/persistence.properties The former is used for tests and for embedded mode, the latter for production, e.g. for the WAR to be deployed into a real-world deployment. HTH Regards. [1] https://cwiki.apache.org/confluence/display/SYNCOPE/Create+a+new+Syncope+project#CreateanewSyncopeproject-Snapshot(development)releases [2] https://cwiki.apache.org/confluence/display/SYNCOPE/Run+Syncope+in+embedded+mode [3] https://cwiki.apache.org/confluence/display/SYNCOPE/Run+Syncope+standalone+distribution#RunSyncopestandalonedistribution-Internalstorage -- 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/
[jira] [Commented] (SYNCOPE-473) Provide configuration interface for push tasks
[ https://issues.apache.org/jira/browse/SYNCOPE-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14043214#comment-14043214 ] ASF subversion and git services commented on SYNCOPE-473: - Commit 1605296 from [~andrea.patricelli] in branch 'syncope/trunk' [ https://svn.apache.org/r1605296 ] [SYNCOPE-473] changed default Unmatching rule for sync task to PROVISION > Provide configuration interface for push tasks > -- > > Key: SYNCOPE-473 > URL: https://issues.apache.org/jira/browse/SYNCOPE-473 > Project: Syncope > Issue Type: Sub-task > Components: console >Affects Versions: 1.2.0 >Reporter: fabio martelli >Assignee: Andrea Patricelli > Fix For: 1.2.0 > > > Provide configuration interface for push tasks like done for sync and sched > tasks -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Task "Rules"
Il 25/06/2014 08:28, Francesco Chicchiriccò ha scritto: Hi, it seems that this problem - probably related to SYNCOPE-473 - is blocking the finalization of SYNCOPE-505: Fabio, Andrea, who is going to take a look at what is happening? Hi Colm, I worked on this issue. You and Francesco were right, the problem was in Sync Task Unmatching rule default value set in console SyncTaskModalPage. In order to make LDAPPasswordSyncActions working fine as you expected, sync task needs to have Unmatching rule set to PROVISION (and not to ASSIGN that is Push Task default Unmatching rule value). Side note: we absolutely need to document this amazing new feature (Push and matching / unmatching rules). Regards. On 24/06/2014 13:18, Colm O hEigeartaigh wrote: Ok, thanks for the explanation! I suspect it is a UI bug caused by the merge for SYNCOPE-473, as it was definately working for me last week: https://issues.apache.org/jira/browse/SYNCOPE-473 Colm. On Tue, Jun 24, 2014 at 11:50 AM, Fabio Martelli wrote: Il 24/06/2014 12:24, Colm O hEigeartaigh ha scritto: Hi all, What are the new task "rules" that have been added to trunk? When I create a new synchronization task with the default "Matching/Update" "Unmatching/Assign", it appears that the selected LDAPPasswordSyncActions class is not run. Colm. Hi Colm, matching/unmatching rules can be configured in order to specify a specific behaviour in case of matching (sync user found locally) and unmatching (sync user not found locally) scenarios. For example, I can ask to syncope to unlink the synchronized resource from the local account that matches the synchronized one. This is the issue [1], still in progress: maybe you are facing with a bug (maybe just on the admin console). If you can/want, please investigate more, otherwise, be patient: we will fix it very soon. Best regards, F. [1] https://issues.apache.org/jira/browse/SYNCOPE-471 Best regards, Andrea -- Dott. Andrea Patricelli Tel +393204524292 Junior Engineer @ Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +390859116307 / FAX +39 085973 http://www.tirasa.net
[jira] [Commented] (SYNCOPE-486) Update Selenium test configuration
[ https://issues.apache.org/jira/browse/SYNCOPE-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14043234#comment-14043234 ] ASF subversion and git services commented on SYNCOPE-486: - Commit 1605299 from [~ilgrosso] in branch 'syncope/branches/1_1_X' [ https://svn.apache.org/r1605299 ] [SYNCOPE-486] Refuse in archetype > Update Selenium test configuration > -- > > Key: SYNCOPE-486 > URL: https://issues.apache.org/jira/browse/SYNCOPE-486 > Project: Syncope > Issue Type: Improvement > Components: console >Reporter: Francesco Chicchiriccò >Assignee: Andrea Patricelli > Labels: selenium, test > Fix For: 1.1.8, 1.2.0 > > > Currently Selenium is configured, for admin console, to run via > selenium-maven-plugin, updated to Selenium 2.30. > Unfortunately, this version is reported [1] to have a long-standing bug with > latest (>= 23.0) Firefox versions. > It seems that Selenium 2.40 solves such issue, but it requires a Maven > configuration change, according to [2] > [1] https://code.google.com/p/selenium/issues/detail?id=6112 > [2] http://docs.seleniumhq.org/download/maven.jsp -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Running Syncope Embed using a permanent h2 instance
Hi Denis, this problem is fixed now in the branch 1_1_X; you will need either to build 1.1.8-SNAPSHOT locally or to wait for Jenkins to publish these artifacts (job #181) https://builds.apache.org/view/S-Z/view/Syncope/job/Syncope-1_1_X/ Regards. On 25/06/2014 09:54, Denis Signoretto wrote: Hi Francesco, thanks for your answer. As you suggested I've changed core/src/test/resources/persistence.properties but I still can't set H2 basedir outside workdir. In core.log I get this exception: org.h2.jdbc.JdbcSQLException: IO Exception: outside /apache-tomcat-7.0.53/work/Catalina/localhost/syncope-build-tools After some investigation I saw that build-tools project use a second instance of H2 and in the class H2StartStopListener it sets the H2 baseDir to work dir. I'm not an expert of H2 but it seems baseDir it's a system property that affects all instances. What's the best way to do you suggest to set basedir for syncope db outside work ? Thanks, Denis. -Messaggio originale- Da: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Inviato: martedì 24 giugno 2014 15:35 A: dev@syncope.apache.org Oggetto: Re: Running Syncope Embed using a permanent h2 instance On 24/06/2014 15:27, Denis Signoretto wrote: Hi, I've checked out Syncope 1_1_X to do some tests. I've seen that Syncope h2 db it's created within target directory. Everytime I launch mvn -P debug, target dir it's deleted. This means you are directly running from the actual Syncope sources: I'd suggest you instead to generate your own project from SNAPSHOT archetype [1] and then run in embedded mode [2] via mvn -P embedded. I'm wondering if is there a way to launch Syncope embed mode/debug profile using a permanent h2 location. I've tried adding a customized persistence.properties file in syncope-console\src\resources specifying both absolute and relative path outside target dir but it seems workdir it's needed. Is there a better way to do it or get the same result ? You can proceed similar to the standalone distribution [3]: only, you need to change core/src/test/resources/persistence.properties not core/src/main/resources/persistence.properties The former is used for tests and for embedded mode, the latter for production, e.g. for the WAR to be deployed into a real-world deployment. HTH Regards. [1] https://cwiki.apache.org/confluence/display/SYNCOPE/Create+a+new+Syncope+project#CreateanewSyncopeproject-Snapshot(development)releases [2] https://cwiki.apache.org/confluence/display/SYNCOPE/Run+Syncope+in+embedded+mode [3] https://cwiki.apache.org/confluence/display/SYNCOPE/Run+Syncope+standalone+distribution#RunSyncopestandalonedistribution-Internalstorage -- 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/
R: Running Syncope Embed using a permanent h2 instance
The solution I found ATM was: modifying H2StartStopListener, remove basedir param, rebuild and installed build-tools in maven local repo. I'm wondering if there is a better way to get same result without source code modification of syncope-tools. Thanks, Denis. -Messaggio originale- Da: Denis Signoretto [mailto:denis.signore...@intesys.it] Inviato: mercoledì 25 giugno 2014 09:55 A: dev@syncope.apache.org Oggetto: R: Running Syncope Embed using a permanent h2 instance Hi Francesco, thanks for your answer. As you suggested I've changed core/src/test/resources/persistence.properties but I still can't set H2 basedir outside workdir. In core.log I get this exception: org.h2.jdbc.JdbcSQLException: IO Exception: outside /apache-tomcat-7.0.53/work/Catalina/localhost/syncope-build-tools After some investigation I saw that build-tools project use a second instance of H2 and in the class H2StartStopListener it sets the H2 baseDir to work dir. I'm not an expert of H2 but it seems baseDir it's a system property that affects all instances. What's the best way to do you suggest to set basedir for syncope db outside work ? Thanks, Denis. -Messaggio originale- Da: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Inviato: martedì 24 giugno 2014 15:35 A: dev@syncope.apache.org Oggetto: Re: Running Syncope Embed using a permanent h2 instance On 24/06/2014 15:27, Denis Signoretto wrote: > Hi, > I've checked out Syncope 1_1_X to do some tests. I've seen that Syncope h2 db > it's created within target directory. > Everytime I launch mvn -P debug, target dir it's deleted. This means you are directly running from the actual Syncope sources: I'd suggest you instead to generate your own project from SNAPSHOT archetype [1] and then run in embedded mode [2] via mvn -P embedded. > I'm wondering if is there a way to launch Syncope embed mode/debug profile > using a permanent h2 location. > I've tried adding a customized persistence.properties file in > syncope-console\src\resources specifying both absolute and relative path > outside target dir but it seems workdir it's needed. > > Is there a better way to do it or get the same result ? You can proceed similar to the standalone distribution [3]: only, you need to change core/src/test/resources/persistence.properties not core/src/main/resources/persistence.properties The former is used for tests and for embedded mode, the latter for production, e.g. for the WAR to be deployed into a real-world deployment. HTH Regards. [1] https://cwiki.apache.org/confluence/display/SYNCOPE/Create+a+new+Syncope+project#CreateanewSyncopeproject-Snapshot(development)releases [2] https://cwiki.apache.org/confluence/display/SYNCOPE/Run+Syncope+in+embedded+mode [3] https://cwiki.apache.org/confluence/display/SYNCOPE/Run+Syncope+standalone+distribution#RunSyncopestandalonedistribution-Internalstorage -- 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/
R: Running Syncope Embed using a permanent h2 instance
Hi Francesco, I've just seen you have done the same modification in sources. Thanks! Denis. -Messaggio originale- Da: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Inviato: mercoledì 25 giugno 2014 11:28 A: dev@syncope.apache.org Oggetto: Re: Running Syncope Embed using a permanent h2 instance Hi Denis, this problem is fixed now in the branch 1_1_X; you will need either to build 1.1.8-SNAPSHOT locally or to wait for Jenkins to publish these artifacts (job #181) https://builds.apache.org/view/S-Z/view/Syncope/job/Syncope-1_1_X/ Regards. On 25/06/2014 09:54, Denis Signoretto wrote: > Hi Francesco, > > thanks for your answer. As you suggested I've changed > core/src/test/resources/persistence.properties > but I still can't set H2 basedir outside workdir. In core.log I get this > exception: > > org.h2.jdbc.JdbcSQLException: IO Exception: outside > /apache-tomcat-7.0.53/work/Catalina/localhost/ > syncope-build-tools > > After some investigation I saw that build-tools project use a second > instance of H2 and in the class H2StartStopListener it sets the H2 baseDir to > work dir. > > I'm not an expert of H2 but it seems baseDir it's a system property that > affects all instances. > > What's the best way to do you suggest to set basedir for syncope db outside > work ? > > Thanks, > Denis. > > -Messaggio originale- > Da: Francesco Chicchiriccò [mailto:ilgro...@apache.org] > Inviato: martedì 24 giugno 2014 15:35 > A: dev@syncope.apache.org > Oggetto: Re: Running Syncope Embed using a permanent h2 instance > > On 24/06/2014 15:27, Denis Signoretto wrote: >> Hi, >> I've checked out Syncope 1_1_X to do some tests. I've seen that Syncope h2 >> db it's created within target directory. >> Everytime I launch mvn -P debug, target dir it's deleted. > This means you are directly running from the actual Syncope sources: I'd > suggest you instead to generate your own project from SNAPSHOT archetype [1] > and then run in embedded mode [2] via mvn -P embedded. > >> I'm wondering if is there a way to launch Syncope embed mode/debug profile >> using a permanent h2 location. >> I've tried adding a customized persistence.properties file in >> syncope-console\src\resources specifying both absolute and relative path >> outside target dir but it seems workdir it's needed. >> >> Is there a better way to do it or get the same result ? > You can proceed similar to the standalone distribution [3]: only, you > need to change > > core/src/test/resources/persistence.properties > > not > > core/src/main/resources/persistence.properties > > The former is used for tests and for embedded mode, the latter for > production, e.g. for the WAR to be deployed into a real-world deployment. > > HTH > Regards. > > [1] > https://cwiki.apache.org/confluence/display/SYNCOPE/Create+a+new+Synco > pe+project#CreateanewSyncopeproject-Snapshot(development)releases > [2] > https://cwiki.apache.org/confluence/display/SYNCOPE/Run+Syncope+in+emb > edded+mode > [3] > https://cwiki.apache.org/confluence/display/SYNCOPE/Run+Syncope+standa > lone+distribution#RunSyncopestandalonedistribution-Internalstorage -- 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: Task "Rules"
Il 25/06/2014 11:06, andrea patricelli ha scritto: Il 25/06/2014 08:28, Francesco Chicchiriccò ha scritto: Hi, it seems that this problem - probably related to SYNCOPE-473 - is blocking the finalization of SYNCOPE-505: Fabio, Andrea, who is going to take a look at what is happening? Hi Colm, I worked on this issue. You and Francesco were right, the problem was in Sync Task Unmatching rule default value set in console SyncTaskModalPage. In order to make LDAPPasswordSyncActions working fine as you expected, sync task needs to have Unmatching rule set to PROVISION (and not to ASSIGN that is Push Task default Unmatching rule value). Hi All, please note that action's before method set has been changed a lot. Currently, available options are: * beforeCreate executed before local user/group create in case of unmatching solved with PROVISION rule (default rule) * beforeAssign executed before assigning (create + link) the synchronized resource to a local user/group in case of unmatching solved with ASSIGN rule * beforeUnassign executed before unassigning (unlink + deprovision) the synchronized resource from a local user/group in case of matching solved with UNASSIGN rule * beforeDeprovision executed before deprovisioning (deprovision without unlink) the matching user/group from the synchronized resource in case of matching solved with DEPROVISION rule * beforeUnlink executed before unlinking (unlink without deprovision or update) thematching user/group from the synchronized resource in case of matching solved with UNLINK rule * beforeLink executed before linking (link without update) thematching user/group from the synchronized resource in case of matching solved with LINK rule * beforeUpdate executed before updating the matching user/group in case of matching solved with UPDATE rule (default rule) * beforeDelete executed before deleting a local user/group matching the synchronized removed identity Best regards, F. Side note: we absolutely need to document this amazing new feature (Push and matching / unmatching rules). Regards. On 24/06/2014 13:18, Colm O hEigeartaigh wrote: Ok, thanks for the explanation! I suspect it is a UI bug caused by the merge for SYNCOPE-473, as it was definately working for me last week: https://issues.apache.org/jira/browse/SYNCOPE-473 Colm. On Tue, Jun 24, 2014 at 11:50 AM, Fabio Martelli wrote: Il 24/06/2014 12:24, Colm O hEigeartaigh ha scritto: Hi all, What are the new task "rules" that have been added to trunk? When I create a new synchronization task with the default "Matching/Update" "Unmatching/Assign", it appears that the selected LDAPPasswordSyncActions class is not run. Colm. Hi Colm, matching/unmatching rules can be configured in order to specify a specific behaviour in case of matching (sync user found locally) and unmatching (sync user not found locally) scenarios. For example, I can ask to syncope to unlink the synchronized resource from the local account that matches the synchronized one. This is the issue [1], still in progress: maybe you are facing with a bug (maybe just on the admin console). If you can/want, please investigate more, otherwise, be patient: we will fix it very soon. Best regards, F. [1] https://issues.apache.org/jira/browse/SYNCOPE-471 Best regards, Andrea -- Fabio Martelli Tirasa - Open Source Excellence http://www.tirasa.net/ Apache Syncope PMC http://people.apache.org/~fmartelli/
[jira] [Commented] (SYNCOPE-164) Passthrough authentication
[ https://issues.apache.org/jira/browse/SYNCOPE-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14043267#comment-14043267 ] Colm O hEigeartaigh commented on SYNCOPE-164: - Hi Francesco, I'm wondering if this task might be somewhat straightforward enough to implement for 1.2... If user authentication fails in the SyncopeAuthenticationProvider + if pass through authentication is enabled via a resource property / account policy / etc., then grab the Connectors associated with the user + try to perform authentication using the supplied credentials. Or am I missing something? Colm. > Passthrough authentication > -- > > Key: SYNCOPE-164 > URL: https://issues.apache.org/jira/browse/SYNCOPE-164 > Project: Syncope > Issue Type: Sub-task >Reporter: Francesco Chicchiriccò > Fix For: 3.0.0 > > > Provide the possibility to authenticate users on external resources. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Task "Rules"
Cool, thanks! It's working fine now. Colm. On Wed, Jun 25, 2014 at 10:06 AM, andrea patricelli < andrea.patrice...@tirasa.net> wrote: > Il 25/06/2014 08:28, Francesco Chicchiriccò ha scritto: > > Hi, >> it seems that this problem - probably related to SYNCOPE-473 - is >> blocking the finalization of SYNCOPE-505: Fabio, Andrea, who is going to >> take a look at what is happening? >> >> > Hi Colm, > > I worked on this issue. > You and Francesco were right, the problem was in Sync Task Unmatching rule > default value set in console SyncTaskModalPage. In order to make > LDAPPasswordSyncActions working fine as you expected, sync task needs to > have Unmatching rule set to PROVISION (and not to ASSIGN that is Push Task > default Unmatching rule value). > > > Side note: we absolutely need to document this amazing new feature (Push >> and matching / unmatching rules). >> >> Regards. >> >> On 24/06/2014 13:18, Colm O hEigeartaigh wrote: >> >>> Ok, thanks for the explanation! I suspect it is a UI bug caused by the >>> merge for SYNCOPE-473, as it was definately working for me last week: >>> >>> https://issues.apache.org/jira/browse/SYNCOPE-473 >>> >>> Colm. >>> >>> >>> On Tue, Jun 24, 2014 at 11:50 AM, Fabio Martelli < >>> fabio.marte...@gmail.com> >>> wrote: >>> >>> Il 24/06/2014 12:24, Colm O hEigeartaigh ha scritto: Hi all, > What are the new task "rules" that have been added to trunk? When I > create > a new synchronization task with the default "Matching/Update" > "Unmatching/Assign", it appears that the selected > LDAPPasswordSyncActions > class is not run. > > Colm. > > > Hi Colm, matching/unmatching rules can be configured in order to > specify > a specific behaviour in case of matching (sync user found locally) and unmatching (sync user not found locally) scenarios. For example, I can ask to syncope to unlink the synchronized resource from the local account that matches the synchronized one. This is the issue [1], still in progress: maybe you are facing with a bug (maybe just on the admin console). If you can/want, please investigate more, otherwise, be patient: we will fix it very soon. Best regards, F. [1] https://issues.apache.org/jira/browse/SYNCOPE-471 >>> >> Best regards, > Andrea > > -- > Dott. Andrea Patricelli > Tel +393204524292 > > Junior Engineer @ Tirasa S.r.l. > Viale D'Annunzio 267 - 65127 Pescara > Tel +390859116307 / FAX +39 085973 > http://www.tirasa.net > > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
[jira] [Resolved] (SYNCOPE-505) Support propagating non-cleartext passwords to external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh resolved SYNCOPE-505.
-
Resolution: Fixed
> Support propagating non-cleartext passwords to external resources
> -
>
> Key: SYNCOPE-505
> URL: https://issues.apache.org/jira/browse/SYNCOPE-505
> Project: Syncope
> Issue Type: Improvement
> Components: core
>Reporter: Francesco Chicchiriccò
>Assignee: Colm O hEigeartaigh
> Fix For: 1.2.0
>
>
> Similarly to SYNCOPE-313 during synchronization, it seems feasible to provide
> some Propagation Actions classes (say {{DBPasswordPropagationActions}} and
> {{LDAPPasswordPropagationActions}} that will propagate non-cleartext password
> values to external resources.
> This might require some changes in the related connector bundles.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SYNCOPE-164) Passthrough authentication
[
https://issues.apache.org/jira/browse/SYNCOPE-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14043289#comment-14043289
]
Francesco Chicchiriccò commented on SYNCOPE-164:
Well, this issue was originally meant for full Access Management scenario but
it is indeed true that it could be implemented in 1.2.
I think that adding a property to {{AccountPolicy}} is a good point: one can
think to add an 'Authentication chain' list field which can contain any
resource flagged for authentication + the internal storage, in a given order.
At this point the {{SyncopeAuthenticationProvider}} will first get the
{{AccountPolicy}} for the authenticating user and then attempt to use the
provided credentials to authenticate against the given resources: the first
that succeeds will make the user authenticated.
WDYT?
> Passthrough authentication
> --
>
> Key: SYNCOPE-164
> URL: https://issues.apache.org/jira/browse/SYNCOPE-164
> Project: Syncope
> Issue Type: Sub-task
>Reporter: Francesco Chicchiriccò
> Fix For: 3.0.0
>
>
> Provide the possibility to authenticate users on external resources.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SYNCOPE-164) Passthrough authentication
[ https://issues.apache.org/jira/browse/SYNCOPE-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14043298#comment-14043298 ] Colm O hEigeartaigh commented on SYNCOPE-164: - Sure, sounds good! Can you give me a pointer on how I can go from a ConnInstance/Connector to calling "authenticate" via ConnId's AuthenticateOp (or is there another way?) Colm. > Passthrough authentication > -- > > Key: SYNCOPE-164 > URL: https://issues.apache.org/jira/browse/SYNCOPE-164 > Project: Syncope > Issue Type: Sub-task >Reporter: Francesco Chicchiriccò > Fix For: 3.0.0 > > > Provide the possibility to authenticate users on external resources. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SYNCOPE-164) Passthrough authentication
[ https://issues.apache.org/jira/browse/SYNCOPE-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated SYNCOPE-164: --- Fix Version/s: (was: 3.0.0) 1.2.0 > Passthrough authentication > -- > > Key: SYNCOPE-164 > URL: https://issues.apache.org/jira/browse/SYNCOPE-164 > Project: Syncope > Issue Type: Sub-task >Reporter: Francesco Chicchiriccò > Fix For: 1.2.0 > > > Provide the possibility to authenticate users on external resources. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SYNCOPE-164) Passthrough authentication
[ https://issues.apache.org/jira/browse/SYNCOPE-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated SYNCOPE-164: --- Issue Type: New Feature (was: Sub-task) Parent: (was: SYNCOPE-160) > Passthrough authentication > -- > > Key: SYNCOPE-164 > URL: https://issues.apache.org/jira/browse/SYNCOPE-164 > Project: Syncope > Issue Type: New Feature >Reporter: Francesco Chicchiriccò > Fix For: 1.2.0 > > > Provide the possibility to authenticate users on external resources. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SYNCOPE-164) Passthrough authentication
[
https://issues.apache.org/jira/browse/SYNCOPE-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14043306#comment-14043306
]
Francesco Chicchiriccò commented on SYNCOPE-164:
You need to extend the {{Connector}} interface with an {{authenticate()}}
method and modify accordingly {{ConnectorFacadeProxy}} and
{{AsyncConnectorFacade}}.
> Passthrough authentication
> --
>
> Key: SYNCOPE-164
> URL: https://issues.apache.org/jira/browse/SYNCOPE-164
> Project: Syncope
> Issue Type: New Feature
>Reporter: Francesco Chicchiriccò
> Fix For: 1.2.0
>
>
> Provide the possibility to authenticate users on external resources.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (SYNCOPE-164) Passthrough authentication
[ https://issues.apache.org/jira/browse/SYNCOPE-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned SYNCOPE-164: --- Assignee: Colm O hEigeartaigh > Passthrough authentication > -- > > Key: SYNCOPE-164 > URL: https://issues.apache.org/jira/browse/SYNCOPE-164 > Project: Syncope > Issue Type: New Feature >Reporter: Francesco Chicchiriccò >Assignee: Colm O hEigeartaigh > Fix For: 1.2.0 > > > Provide the possibility to authenticate users on external resources. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SYNCOPE-505) Support propagating non-cleartext passwords to external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14043316#comment-14043316
]
Francesco Chicchiriccò commented on SYNCOPE-505:
Any plan for adding an integration test case for this feature?
> Support propagating non-cleartext passwords to external resources
> -
>
> Key: SYNCOPE-505
> URL: https://issues.apache.org/jira/browse/SYNCOPE-505
> Project: Syncope
> Issue Type: Improvement
> Components: core
>Reporter: Francesco Chicchiriccò
>Assignee: Colm O hEigeartaigh
> Fix For: 1.2.0
>
>
> Similarly to SYNCOPE-313 during synchronization, it seems feasible to provide
> some Propagation Actions classes (say {{DBPasswordPropagationActions}} and
> {{LDAPPasswordPropagationActions}} that will propagate non-cleartext password
> values to external resources.
> This might require some changes in the related connector bundles.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SYNCOPE-313) Support synchronizing non-cleartext passwords from external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14043317#comment-14043317
]
Francesco Chicchiriccò commented on SYNCOPE-313:
Any plan for adding an integration test case for this feature?
> Support synchronizing non-cleartext passwords from external resources
> -
>
> Key: SYNCOPE-313
> URL: https://issues.apache.org/jira/browse/SYNCOPE-313
> Project: Syncope
> Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 1.2.0
>
>
> Currently we can synchronize cleartext passwords from external resources.
> However, we can't handle non-cleartext passwords, as they get treated as if
> they are plaintext passwords when imported into Syncope, and hence hashed
> again according to user.cipherAlgorithm().
> This task is to treat an imported password as hashed according to a give
> cipher algorithm configured on the connector (for example via 'Password
> Cipher Algorithm' for the DB Connector).
> This is specific to each individual connector, as for example for the DB
> Connector, it might just be a hashed value stored in a table, whereas for
> LDAP it'll be of the form "CIPHER}VALUE" etc.
> Note that we 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 {
> ...
> }
> }
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (SYNCOPE-392) Full reconciliation from syncope to resource
[ https://issues.apache.org/jira/browse/SYNCOPE-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated SYNCOPE-392: --- Summary: Full reconciliation from syncope to resource (was: full reconciliation from syncope to resource) > Full reconciliation from syncope to resource > > > Key: SYNCOPE-392 > URL: https://issues.apache.org/jira/browse/SYNCOPE-392 > Project: Syncope > Issue Type: Improvement > Components: console, core >Affects Versions: 1.1.4, 1.2.0 >Reporter: fabio martelli >Assignee: fabio martelli >Priority: Minor > Fix For: 1.2.0 > > > Implement a full reconciliation from syncope towards a specific resource. > Unmatching (user found on syncope but not on the resource): > * ignore; > * unlink the resource (keep user on syncope and remove resource link) > * create (create user on resource - if create capability is given) > * delete (remove user on syncope) > Matching (users found on syncope and on the resource): > * ignore > * update > * unlink (perform deprovisioning - if delete capability is given) > * delete (delete on syncope and perform deprovisioning - if delete capability > is given) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SYNCOPE-515) Bad integration test causes role ownership conflicts
[ https://issues.apache.org/jira/browse/SYNCOPE-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14043369#comment-14043369 ] ASF subversion and git services commented on SYNCOPE-515: - Commit 1605361 from [~fmartelli] in branch 'syncope/trunk' [ https://svn.apache.org/r1605361 ] [SYNCOPE-504, SYNCOPE-515] merge from the branch 1_1_X > Bad integration test causes role ownership conflicts > > > Key: SYNCOPE-515 > URL: https://issues.apache.org/jira/browse/SYNCOPE-515 > Project: Syncope > Issue Type: Bug >Affects Versions: 1.1.7, 1.2.0 >Reporter: fabio martelli >Assignee: fabio martelli > Fix For: 1.1.8, 1.2.0 > > > Reproduce with > mvn clean verify -Dit.test=*e*TestITCase -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SYNCOPE-504) Sync/Push actions shouldn't be executed in dryrun
[ https://issues.apache.org/jira/browse/SYNCOPE-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14043368#comment-14043368 ] ASF subversion and git services commented on SYNCOPE-504: - Commit 1605361 from [~fmartelli] in branch 'syncope/trunk' [ https://svn.apache.org/r1605361 ] [SYNCOPE-504, SYNCOPE-515] merge from the branch 1_1_X > Sync/Push actions shouldn't be executed in dryrun > - > > Key: SYNCOPE-504 > URL: https://issues.apache.org/jira/browse/SYNCOPE-504 > Project: Syncope > Issue Type: Bug > Components: core >Affects Versions: 1.1.7, 1.2.0 >Reporter: fabio martelli >Assignee: fabio martelli > Fix For: 1.1.8, 1.2.0 > > > Provide changes into SyncopeSyncResultHandler and SyncopePushResultHandler in > order to avoid to execute actions in DryRun mode (please note: a code > refactoring is required by sync/push restult handler). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (SYNCOPE-515) Bad integration test causes role ownership conflicts
[ https://issues.apache.org/jira/browse/SYNCOPE-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] fabio martelli resolved SYNCOPE-515. Resolution: Fixed > Bad integration test causes role ownership conflicts > > > Key: SYNCOPE-515 > URL: https://issues.apache.org/jira/browse/SYNCOPE-515 > Project: Syncope > Issue Type: Bug >Affects Versions: 1.1.7, 1.2.0 >Reporter: fabio martelli >Assignee: fabio martelli > Fix For: 1.1.8, 1.2.0 > > > Reproduce with > mvn clean verify -Dit.test=*e*TestITCase -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (SYNCOPE-504) Sync/Push actions shouldn't be executed in dryrun
[ https://issues.apache.org/jira/browse/SYNCOPE-504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] fabio martelli resolved SYNCOPE-504. Resolution: Fixed > Sync/Push actions shouldn't be executed in dryrun > - > > Key: SYNCOPE-504 > URL: https://issues.apache.org/jira/browse/SYNCOPE-504 > Project: Syncope > Issue Type: Bug > Components: core >Affects Versions: 1.1.7, 1.2.0 >Reporter: fabio martelli >Assignee: fabio martelli > Fix For: 1.1.8, 1.2.0 > > > Provide changes into SyncopeSyncResultHandler and SyncopePushResultHandler in > order to avoid to execute actions in DryRun mode (please note: a code > refactoring is required by sync/push restult handler). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SYNCOPE-471) Provide matching/unmatchig rule management for push tasks
[ https://issues.apache.org/jira/browse/SYNCOPE-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] fabio martelli updated SYNCOPE-471: --- Description: Provide matching/unmatching rule management: Unmatching (user found on syncope but not on the resource and viceversa): * IGNORE (Do not perform any action); * UNLINK (Just unlink resource without performing any (de-)provisioning operation; in case of sync task UNLINK and IGNORE will coincide); * ASSIGN (Link the resource and create entity); * PROVISION (Create entity without linking the resource). Matching (users found on syncope and on the resource): * IGNORE (Do not perform any action); * UPDATE (Update matching entity); * DEPROVISION (Delete resource entity); * UNASSIGN (Unlink resource and delete resource entity) ; * UNLINK (Just unlink resource without performing any (de-)provisioning operation); * LINK (Just link resource without performing any (de-)provisioning operation). was: Provide matching/unmatching rule management: Unmatching (user found on syncope but not on the resource): * ignore; * unlink the resource (keep user on syncope and remove resource link) * create (create user on resource - if create capability is given) * delete (remove user on syncope) Matching (users found on syncope and on the resource): * ignore * update * unlink (perform deprovisioning - if delete capability is given) * delete (delete on syncope and perform deprovisioning - if delete capability is given) > Provide matching/unmatchig rule management for push tasks > - > > Key: SYNCOPE-471 > URL: https://issues.apache.org/jira/browse/SYNCOPE-471 > Project: Syncope > Issue Type: Sub-task > Components: console, core >Affects Versions: 1.2.0 >Reporter: fabio martelli >Assignee: fabio martelli > Fix For: 1.2.0 > > > Provide matching/unmatching rule management: > Unmatching (user found on syncope but not on the resource and viceversa): > * IGNORE (Do not perform any action); > * UNLINK (Just unlink resource without performing any (de-)provisioning > operation; in case of sync task UNLINK and IGNORE will coincide); > * ASSIGN (Link the resource and create entity); > * PROVISION (Create entity without linking the resource). > Matching (users found on syncope and on the resource): > * IGNORE (Do not perform any action); > * UPDATE (Update matching entity); > * DEPROVISION (Delete resource entity); > * UNASSIGN (Unlink resource and delete resource entity) ; > * UNLINK (Just unlink resource without performing any (de-)provisioning > operation); > * LINK (Just link resource without performing any (de-)provisioning > operation). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SYNCOPE-461) Use BeanValidation 1.1 with JAX-RS services
[ https://issues.apache.org/jira/browse/SYNCOPE-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14043428#comment-14043428 ] ASF subversion and git services commented on SYNCOPE-461: - Commit 1605386 from [~ilgrosso] in branch 'syncope/trunk' [ https://svn.apache.org/r1605386 ] [SYNCOPE-461] Implementation provided > Use BeanValidation 1.1 with JAX-RS services > --- > > Key: SYNCOPE-461 > URL: https://issues.apache.org/jira/browse/SYNCOPE-461 > Project: Syncope > Issue Type: Improvement > Components: common, core >Reporter: Francesco Chicchiriccò >Assignee: Francesco Chicchiriccò > Labels: rest > Fix For: 1.2.0 > > > CXF supports JAX-RS bean validation 1.1 [1]. > Unfortunately, the available implementations are either Hibernate Validator > or Apache BVal 1.0, not yet released (1.0-alpha-SNAPSHOT available). > Syncope already features BVal 0.5 for OpenJPA bean validation, so the logical > choice is to wait for BVal 1.0 to be generally available. > [1] http://cxf.apache.org/docs/validationfeature.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SYNCOPE-513) Make value encryption parametric
[
https://issues.apache.org/jira/browse/SYNCOPE-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò updated SYNCOPE-513:
---
Description:
In {{PasswordEncoder}} (1.1.X) / {{Encryptor}} (1.2.X) class the salt mechanism
configuration is hardcoded
If the LDAP server doesn't use the same salt mechanism configuration, the
password can't be matched during authentication.
For example SSHA digest from OpenDJ uses a suffixed 8 bytes salt (in hash and
plan)
Original:
digester.setIterations(10);
digester.setSaltSizeBytes(16);
Modified for OpenDJ
digester.setIterations(1);
digester.setSaltSizeBytes(8);
digester.setInvertPositionOfPlainSaltInEncryptionResults(true);
digester.setInvertPositionOfSaltInMessageBeforeDigesting(true);
{{Encryptor}} can read from global configuration parameters so that you can
configure some aspect of the way how ciphered values (not only password values
in 1.2.X).
was:
In PasswordEncoder class the salt mechanism configuration is hardcoded
If the LDAP doesn't use the same salt mechanism configuration, the password
can't be matched during authentication.
For example SSHA digest from OpenDJ uses a suffixed 8 bytes salt (in hash and
plan)
Original:
digester.setIterations(10);
digester.setSaltSizeBytes(16);
Modified for OpenDJ
digester.setIterations(1);
digester.setSaltSizeBytes(8);
digester.setInvertPositionOfPlainSaltInEncryptionResults(true);
digester.setInvertPositionOfSaltInMessageBeforeDigesting(true);
Maybe adding a way to configure custom cipher algorithms will allow more
widespread interoperability with existing LDAPv3 implementations in the market
Environment: (was: OpenDJ as LDAP)
Fix Version/s: 1.2.0
Issue Type: Improvement (was: Bug)
Summary: Make value encryption parametric (was: Salted cipher
algorithms incompatible interoperability with OpenDJ)
> Make value encryption parametric
>
>
> Key: SYNCOPE-513
> URL: https://issues.apache.org/jira/browse/SYNCOPE-513
> Project: Syncope
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.1.8
>Reporter: Yann Diorcet
> Fix For: 1.2.0
>
>
> In {{PasswordEncoder}} (1.1.X) / {{Encryptor}} (1.2.X) class the salt
> mechanism configuration is hardcoded
> If the LDAP server doesn't use the same salt mechanism configuration, the
> password can't be matched during authentication.
> For example SSHA digest from OpenDJ uses a suffixed 8 bytes salt (in hash and
> plan)
> Original:
> digester.setIterations(10);
> digester.setSaltSizeBytes(16);
> Modified for OpenDJ
> digester.setIterations(1);
> digester.setSaltSizeBytes(8);
> digester.setInvertPositionOfPlainSaltInEncryptionResults(true);
> digester.setInvertPositionOfSaltInMessageBeforeDigesting(true);
> {{Encryptor}} can read from global configuration parameters so that you can
> configure some aspect of the way how ciphered values (not only password
> values in 1.2.X).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (SYNCOPE-461) Use BeanValidation 1.1 with JAX-RS services
[ https://issues.apache.org/jira/browse/SYNCOPE-461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò resolved SYNCOPE-461. Resolution: Fixed > Use BeanValidation 1.1 with JAX-RS services > --- > > Key: SYNCOPE-461 > URL: https://issues.apache.org/jira/browse/SYNCOPE-461 > Project: Syncope > Issue Type: Improvement > Components: common, core >Reporter: Francesco Chicchiriccò >Assignee: Francesco Chicchiriccò > Labels: rest > Fix For: 1.2.0 > > > CXF supports JAX-RS bean validation 1.1 [1]. > Unfortunately, the available implementations are either Hibernate Validator > or Apache BVal 1.0, not yet released (1.0-alpha-SNAPSHOT available). > Syncope already features BVal 0.5 for OpenJPA bean validation, so the logical > choice is to wait for BVal 1.0 to be generally available. > [1] http://cxf.apache.org/docs/validationfeature.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SYNCOPE-513) Make value encryption parametric
[
https://issues.apache.org/jira/browse/SYNCOPE-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò updated SYNCOPE-513:
---
Description:
In {{PasswordEncoder}} (1.1.X) / {{Encryptor}} (1.2.X) class the salt mechanism
configuration is hardcoded
If the LDAP server doesn't use the same salt mechanism configuration, the
password can't be matched during authentication.
For example SSHA digest from OpenDJ uses a suffixed 8 bytes salt (in hash and
plan)
Original:
{code}
digester.setIterations(10);
digester.setSaltSizeBytes(16);
{code}
Modified for OpenDJ:
{code}
digester.setIterations(1);
digester.setSaltSizeBytes(8);
digester.setInvertPositionOfPlainSaltInEncryptionResults(true);
digester.setInvertPositionOfSaltInMessageBeforeDigesting(true);
{code}
{{Encryptor}} can read from global configuration parameters so that you can
configure some aspect of the way how ciphered values (not only password values
in 1.2.X).
was:
In {{PasswordEncoder}} (1.1.X) / {{Encryptor}} (1.2.X) class the salt mechanism
configuration is hardcoded
If the LDAP server doesn't use the same salt mechanism configuration, the
password can't be matched during authentication.
For example SSHA digest from OpenDJ uses a suffixed 8 bytes salt (in hash and
plan)
Original:
digester.setIterations(10);
digester.setSaltSizeBytes(16);
Modified for OpenDJ
digester.setIterations(1);
digester.setSaltSizeBytes(8);
digester.setInvertPositionOfPlainSaltInEncryptionResults(true);
digester.setInvertPositionOfSaltInMessageBeforeDigesting(true);
{{Encryptor}} can read from global configuration parameters so that you can
configure some aspect of the way how ciphered values (not only password values
in 1.2.X).
> Make value encryption parametric
>
>
> Key: SYNCOPE-513
> URL: https://issues.apache.org/jira/browse/SYNCOPE-513
> Project: Syncope
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.1.8
>Reporter: Yann Diorcet
> Fix For: 1.2.0
>
>
> In {{PasswordEncoder}} (1.1.X) / {{Encryptor}} (1.2.X) class the salt
> mechanism configuration is hardcoded
> If the LDAP server doesn't use the same salt mechanism configuration, the
> password can't be matched during authentication.
> For example SSHA digest from OpenDJ uses a suffixed 8 bytes salt (in hash and
> plan)
> Original:
> {code}
> digester.setIterations(10);
> digester.setSaltSizeBytes(16);
> {code}
> Modified for OpenDJ:
> {code}
> digester.setIterations(1);
> digester.setSaltSizeBytes(8);
> digester.setInvertPositionOfPlainSaltInEncryptionResults(true);
> digester.setInvertPositionOfSaltInMessageBeforeDigesting(true);
> {code}
> {{Encryptor}} can read from global configuration parameters so that you can
> configure some aspect of the way how ciphered values (not only password
> values in 1.2.X).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SYNCOPE-513) Make value encryption parametric
[
https://issues.apache.org/jira/browse/SYNCOPE-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14043460#comment-14043460
]
Colm O hEigeartaigh commented on SYNCOPE-513:
-
I can take this on, unless someone else wants to fix it?
Colm.
> Make value encryption parametric
>
>
> Key: SYNCOPE-513
> URL: https://issues.apache.org/jira/browse/SYNCOPE-513
> Project: Syncope
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.1.8
>Reporter: Yann Diorcet
> Fix For: 1.2.0
>
>
> In {{PasswordEncoder}} (1.1.X) / {{Encryptor}} (1.2.X) class the salt
> mechanism configuration is hardcoded
> If the LDAP server doesn't use the same salt mechanism configuration, the
> password can't be matched during authentication.
> For example SSHA digest from OpenDJ uses a suffixed 8 bytes salt (in hash and
> plan)
> Original:
> {code}
> digester.setIterations(10);
> digester.setSaltSizeBytes(16);
> {code}
> Modified for OpenDJ:
> {code}
> digester.setIterations(1);
> digester.setSaltSizeBytes(8);
> digester.setInvertPositionOfPlainSaltInEncryptionResults(true);
> digester.setInvertPositionOfSaltInMessageBeforeDigesting(true);
> {code}
> {{Encryptor}} can read from global configuration parameters so that you can
> configure some aspect of the way how ciphered values (not only password
> values in 1.2.X).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SYNCOPE-513) Make value encryption parametric
[
https://issues.apache.org/jira/browse/SYNCOPE-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14043468#comment-14043468
]
Francesco Chicchiriccò commented on SYNCOPE-513:
Fine for me.
I was thinking to empower SYNCOPE-290 for providing few parameters with
sensible defaults: this would imply adding some entries to {{test}}'s and
{{main}}'s {{content.xml}}; should you need any help with this, just shout :-)
> Make value encryption parametric
>
>
> Key: SYNCOPE-513
> URL: https://issues.apache.org/jira/browse/SYNCOPE-513
> Project: Syncope
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.1.8
>Reporter: Yann Diorcet
> Fix For: 1.2.0
>
>
> In {{PasswordEncoder}} (1.1.X) / {{Encryptor}} (1.2.X) class the salt
> mechanism configuration is hardcoded
> If the LDAP server doesn't use the same salt mechanism configuration, the
> password can't be matched during authentication.
> For example SSHA digest from OpenDJ uses a suffixed 8 bytes salt (in hash and
> plan)
> Original:
> {code}
> digester.setIterations(10);
> digester.setSaltSizeBytes(16);
> {code}
> Modified for OpenDJ:
> {code}
> digester.setIterations(1);
> digester.setSaltSizeBytes(8);
> digester.setInvertPositionOfPlainSaltInEncryptionResults(true);
> digester.setInvertPositionOfSaltInMessageBeforeDigesting(true);
> {code}
> {{Encryptor}} can read from global configuration parameters so that you can
> configure some aspect of the way how ciphered values (not only password
> values in 1.2.X).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (SYNCOPE-514) Core doesn't deploy on Glassfish
[ https://issues.apache.org/jira/browse/SYNCOPE-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò reassigned SYNCOPE-514: -- Assignee: Francesco Chicchiriccò (was: Massimiliano Perrone) > Core doesn't deploy on Glassfish > > > Key: SYNCOPE-514 > URL: https://issues.apache.org/jira/browse/SYNCOPE-514 > Project: Syncope > Issue Type: Bug > Components: core >Affects Versions: 1.2.0 > Environment: Glassfish 4 >Reporter: Massimiliano Perrone >Assignee: Francesco Chicchiriccò > Fix For: 1.2.0 > > > Now, trying to deploy the core on Glassfish 4 the result is: > [17:07:50.688][info][talledLocalContainer] remote failure: Error occurred > during deployment: Exception while loading the app : > java.lang.IllegalStateException: ContainerBase.addChild: start: > org.apache.catalina.LifecycleException: > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name 'validator' defined in file > [/tmp/trunk/core/target/syncope-core-test/WEB-INF/classes/persistenceContext.xml]: > Invocation of init method failed; nested exception is > java.lang.AbstractMethodError: > org.apache.bval.jsr303.ConfigurationImpl.getDefaultParameterNameProvider()Ljavax/validation/ParameterNameProvider;. > Please see server.log for more details. > I have been able to deploy it deleting bval dependencies and replacing them > with hibernate-validator libraries. > Considering that SYNCOPE-461 suggests to replace BVal with Hibernate > Validator, what do you think to replace it now? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SYNCOPE-514) Core doesn't deploy on Glassfish
[
https://issues.apache.org/jira/browse/SYNCOPE-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14043556#comment-14043556
]
Francesco Chicchiriccò commented on SYNCOPE-514:
The deploy problems of the {{glassfish-it}} profile are related to [this
issue|https://connid.atlassian.net/browse/SOAP-9] of the SOAP connector.
> Core doesn't deploy on Glassfish
>
>
> Key: SYNCOPE-514
> URL: https://issues.apache.org/jira/browse/SYNCOPE-514
> Project: Syncope
> Issue Type: Bug
> Components: core
>Affects Versions: 1.2.0
> Environment: Glassfish 4
>Reporter: Massimiliano Perrone
>Assignee: Francesco Chicchiriccò
> Fix For: 1.2.0
>
>
> Now, trying to deploy the core on Glassfish 4 the result is:
> [17:07:50.688][info][talledLocalContainer] remote failure: Error occurred
> during deployment: Exception while loading the app :
> java.lang.IllegalStateException: ContainerBase.addChild: start:
> org.apache.catalina.LifecycleException:
> org.springframework.beans.factory.BeanCreationException: Error creating bean
> with name 'validator' defined in file
> [/tmp/trunk/core/target/syncope-core-test/WEB-INF/classes/persistenceContext.xml]:
> Invocation of init method failed; nested exception is
> java.lang.AbstractMethodError:
> org.apache.bval.jsr303.ConfigurationImpl.getDefaultParameterNameProvider()Ljavax/validation/ParameterNameProvider;.
> Please see server.log for more details.
> I have been able to deploy it deleting bval dependencies and replacing them
> with hibernate-validator libraries.
> Considering that SYNCOPE-461 suggests to replace BVal with Hibernate
> Validator, what do you think to replace it now?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SYNCOPE-514) Core doesn't deploy on Glassfish
[ https://issues.apache.org/jira/browse/SYNCOPE-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14043587#comment-14043587 ] ASF subversion and git services commented on SYNCOPE-514: - Commit 1605437 from [~ilgrosso] in branch 'syncope/trunk' [ https://svn.apache.org/r1605437 ] [SYNCOPE-514] Setting SOAP bundle version to 1.2.8 which resolves the problems with Glassfish 4 > Core doesn't deploy on Glassfish > > > Key: SYNCOPE-514 > URL: https://issues.apache.org/jira/browse/SYNCOPE-514 > Project: Syncope > Issue Type: Bug > Components: core >Affects Versions: 1.2.0 > Environment: Glassfish 4 >Reporter: Massimiliano Perrone >Assignee: Francesco Chicchiriccò > Fix For: 1.2.0 > > > Now, trying to deploy the core on Glassfish 4 the result is: > [17:07:50.688][info][talledLocalContainer] remote failure: Error occurred > during deployment: Exception while loading the app : > java.lang.IllegalStateException: ContainerBase.addChild: start: > org.apache.catalina.LifecycleException: > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name 'validator' defined in file > [/tmp/trunk/core/target/syncope-core-test/WEB-INF/classes/persistenceContext.xml]: > Invocation of init method failed; nested exception is > java.lang.AbstractMethodError: > org.apache.bval.jsr303.ConfigurationImpl.getDefaultParameterNameProvider()Ljavax/validation/ParameterNameProvider;. > Please see server.log for more details. > I have been able to deploy it deleting bval dependencies and replacing them > with hibernate-validator libraries. > Considering that SYNCOPE-461 suggests to replace BVal with Hibernate > Validator, what do you think to replace it now? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (SYNCOPE-514) Core doesn't deploy on Glassfish
[ https://issues.apache.org/jira/browse/SYNCOPE-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò resolved SYNCOPE-514. Resolution: Fixed > Core doesn't deploy on Glassfish > > > Key: SYNCOPE-514 > URL: https://issues.apache.org/jira/browse/SYNCOPE-514 > Project: Syncope > Issue Type: Bug > Components: core >Affects Versions: 1.2.0 > Environment: Glassfish 4 >Reporter: Massimiliano Perrone >Assignee: Francesco Chicchiriccò > Fix For: 1.2.0 > > > Now, trying to deploy the core on Glassfish 4 the result is: > [17:07:50.688][info][talledLocalContainer] remote failure: Error occurred > during deployment: Exception while loading the app : > java.lang.IllegalStateException: ContainerBase.addChild: start: > org.apache.catalina.LifecycleException: > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name 'validator' defined in file > [/tmp/trunk/core/target/syncope-core-test/WEB-INF/classes/persistenceContext.xml]: > Invocation of init method failed; nested exception is > java.lang.AbstractMethodError: > org.apache.bval.jsr303.ConfigurationImpl.getDefaultParameterNameProvider()Ljavax/validation/ParameterNameProvider;. > Please see server.log for more details. > I have been able to deploy it deleting bval dependencies and replacing them > with hibernate-validator libraries. > Considering that SYNCOPE-461 suggests to replace BVal with Hibernate > Validator, what do you think to replace it now? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (SYNCOPE-517) Empower ETag from console
[ https://issues.apache.org/jira/browse/SYNCOPE-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò reassigned SYNCOPE-517: -- Assignee: Francesco Chicchiriccò > Empower ETag from console > - > > Key: SYNCOPE-517 > URL: https://issues.apache.org/jira/browse/SYNCOPE-517 > Project: Syncope > Issue Type: Improvement > Components: console >Reporter: Francesco Chicchiriccò >Assignee: Francesco Chicchiriccò > Fix For: 1.2.0 > > > The admin console is not (yet) empowering the ETag feature introduced by > SYNCOPE-429. -- This message was sent by Atlassian JIRA (v6.2#6252)
