2.0.12 GroupTO class cast exception
ource)
~[?:?]
at
org.apache.syncope.client.console.rest.GroupRestClient.create(GroupRestClient.java:46)
~[syncope-client-console-2.0.12.jar:2.0.12]
at
org.apache.syncope.client.console.wizards.any.GroupWizardBuilder.onApplyInternal(GroupWizardBuilder.java:73)
~[syncope-client-console-2.0.12.jar:2.0.12]
at
org.apache.syncope.client.console.wizards.any.GroupWizardBuilder.onApplyInternal(GroupWizardBuilder.java:36)
~[syncope-client-console-2.0.12.jar:2.0.12]
at
org.apache.syncope.client.console.wizards.AjaxWizardBuilder$1.onApplyInternal(AjaxWizardBuilder.java:104)
~[syncope-client-console-2.0.12.jar:2.0.12]
at
org.apache.syncope.client.console.wizards.AjaxWizard$ApplyFuture.call(AjaxWizard.java:423)
~[syncope-client-console-2.0.12.jar:2.0.12]
at
org.apache.syncope.client.console.wizards.AjaxWizard$ApplyFuture.call(AjaxWizard.java:398)
~[syncope-client-console-2.0.12.jar:2.0.12]
at java.util.concurrent.FutureTask.run(Unknown
Source) ~[?:1.8.0_191]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) ~[?:1.8.0_191]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
~[?:1.8.0_191]
... 1 more"
Is this a known issue?
Regards,
Mikael
Mikael Ekblom
CIO
Arcada, IT
Jan-Magnus Janssons plats 1,
FIN-00560 Helsingfors,
Finland
TFn: +358 207 699 467
Mobil: +358 207 699 467
RE: Apache Syncope version 2.1 findings
Hi, As such, the conversion regarding the database went pretty well. One thing though that I found out for the mapping item transformation classes was, that the name of the transformation actions are not shown within the provision interface with their real names when you are about to assign available mapping item transformers. Instead, they are shown with an id string like the following: “MappingItemTransformer_1650f483-5ad5-48bf-90f4-835ad528bf0”. Somehow the “body text” is ignored. As such, this is a valid object identifier, but it is not that helpful…☺. Other pull- and push actions are shown correctly. Another thing I found is, that when you list the resources for a single user through “Manage resources”, the resources themselves are not sorted according to the assigned status as was the case in 2.0.8 for example. The assigned resources are not shown through italic as for the un-assigned resources. But the checkboxes are not checked by default and the assigned resources are not shown first in the list. Should this be this way? Regards, Mikael Mikael Ekblom IT-Service manager Arcada, IT Jan-Magnus Janssons plats 1, FIN-00560 Helsingfors, Finland TFn: +358 207 699 467 Mobil: +358 207 699 467 From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: torstai 12. heinäkuuta 2018 12.01 To: user@syncope.apache.org Subject: Re: Apache Syncope version 2.1 findings On 12/07/2018 10:45, Mikael Ekblom wrote: Hi, Alright, looks good! Another question that I have is for the beforeProvision mapping transformation actions and the MappingItemTransformer class that is mentioned in the documentation: the link from the documentation gives a 404 for this item and I cannot find it within the source either? Is it supposed to be there? Thanks for reporting, MappingItemTransformer should have been ItemTransformer, I have updated the documentation accordingly. In version 2.1, all my transformation actions based on the ItemTransformer interface are not visible anymore. Might be an issue with the previous upgrade too, so I’ll revert back to the latest snapshot and try again from scratch and see. This is a consequence of SYNCOPE-1335: you might want to use https://repository.apache.org/content/groups/snapshots/org/apache/syncope/core/syncope-core-upgrade/2.1.1-SNAPSHOT/syncope-core-upgrade-2.1.1-20180712.064139-8.zip rather than the official syncope-core-upgrade-2.1.0.zip, which contains the fix. Regards. From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: torstai 12. heinäkuuta 2018 9.18 To: user@syncope.apache.org<mailto:user@syncope.apache.org> Subject: Re: Apache Syncope version 2.1 findings FYI, https://cwiki.apache.org/confluence/display/SYNCOPE/Upgrade+from+2.0+Jazz is now complete. Regards. On 11/07/2018 12:21, Francesco Chicchiriccò wrote: On 10/07/2018 17:08, Mikael Ekblom wrote: Hi, I have now tested the 2.1 version or let us say that the installation procedure was tested. My installation path was from 2.0.9. Hi Mikael, thanks for this review. You can find my replies embedded below. I am currently working at a better upgrade page: https://cwiki.apache.org/confluence/display/SYNCOPE/Upgrade+from+2.0+Jazz Regards. My findings are the following: 1. I had the same regarding the Junit version error message regarding syncope console, but I did not delete the junit dependency in the console pom-file. I just added the version information as 4.8.1 dummy value and it went through. Yep, SYNCOPE-1334 addresses this issue. I will add this to the upgrade page. 1. The database script generated the required sql-file as expected, but I had to manually run most of it to double check that i got all the relations and indexes set. I noted during this process that the table ownership was changed from syncope to the default postgres DBA user, so I had to change this manually. This was for the new relations that were created through the sql scipt file. Easily fixed though. I understand, but I think this is expected. It is also the reason why we preferred to generate a SQL script rather than directly executing the generate upgrade statements. BTW, I have found some missing statements (see SYNCOPE-1335), that I will also report in the upgrade page. 1. The core is not so keen on starting...:) The rest is up and running (enduser and syncope-console) but not the core. The log claims the following: * 17:31:00.300 ERROR org.flowable.engine.impl.cmd.ValidateV5EntitiesCmd - Found v5 process definitions that are the latest version. Enable the 'flowable5CompatibilityEnabled' property in the process engine configuration and make sure the flowable5-compatibility dependency is available on the classpath 17:31:00.304 ERROR org.flowable.engine.impl.cmd.ValidateV5EntitiesCmd - Found v5 process definition with id: userWorkflow:61:5012291, and key: userWorkflow I will publish the complete procedure to avoid this
RE: Apache Syncope version 2.1 findings
Hi, Alright, looks good! Another question that I have is for the beforeProvision mapping transformation actions and the MappingItemTransformer class that is mentioned in the documentation: the link from the documentation gives a 404 for this item and I cannot find it within the source either? Is it supposed to be there? In version 2.1, all my transformation actions based on the ItemTransformer interface are not visible anymore. Might be an issue with the previous upgrade too, so I’ll revert back to the latest snapshot and try again from scratch and see. Regards, Mikael Mikael Ekblom IT-Service manager Arcada, IT Jan-Magnus Janssons plats 1, FIN-00560 Helsingfors, Finland TFn: +358 207 699 467 Mobil: +358 207 699 467 From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: torstai 12. heinäkuuta 2018 9.18 To: user@syncope.apache.org Subject: Re: Apache Syncope version 2.1 findings FYI, https://cwiki.apache.org/confluence/display/SYNCOPE/Upgrade+from+2.0+Jazz is now complete. Regards. On 11/07/2018 12:21, Francesco Chicchiriccò wrote: On 10/07/2018 17:08, Mikael Ekblom wrote: Hi, I have now tested the 2.1 version or let us say that the installation procedure was tested. My installation path was from 2.0.9. Hi Mikael, thanks for this review. You can find my replies embedded below. I am currently working at a better upgrade page: https://cwiki.apache.org/confluence/display/SYNCOPE/Upgrade+from+2.0+Jazz Regards. My findings are the following: 1. I had the same regarding the Junit version error message regarding syncope console, but I did not delete the junit dependency in the console pom-file. I just added the version information as 4.8.1 dummy value and it went through. Yep, SYNCOPE-1334 addresses this issue. I will add this to the upgrade page. 1. The database script generated the required sql-file as expected, but I had to manually run most of it to double check that i got all the relations and indexes set. I noted during this process that the table ownership was changed from syncope to the default postgres DBA user, so I had to change this manually. This was for the new relations that were created through the sql scipt file. Easily fixed though. I understand, but I think this is expected. It is also the reason why we preferred to generate a SQL script rather than directly executing the generate upgrade statements. BTW, I have found some missing statements (see SYNCOPE-1335), that I will also report in the upgrade page. 1. The core is not so keen on starting...:) The rest is up and running (enduser and syncope-console) but not the core. The log claims the following: * 17:31:00.300 ERROR org.flowable.engine.impl.cmd.ValidateV5EntitiesCmd - Found v5 process definitions that are the latest version. Enable the 'flowable5CompatibilityEnabled' property in the process engine configuration and make sure the flowable5-compatibility dependency is available on the classpath 17:31:00.304 ERROR org.flowable.engine.impl.cmd.ValidateV5EntitiesCmd - Found v5 process definition with id: userWorkflow:61:5012291, and key: userWorkflow I will publish the complete procedure to avoid this error in the upgrade page. 1. I hope that I do not have to recreate every user due to this error...:) No, not needed, of course. 1. Regarding number 3: can I somehow affect this during run time within workflow.properties or must it be done within the source and the corresponding xml configuration for flowable itself? The flowable engine has not been in use here before. I just do not find out right now where this configuration change should go? Otherwise...all my own customization did compile for version 2.1 also after some modifications. Optional seems to be in pretty heavy use:) More has been packed into interfaces. I will also include the expected code modifications, mainly due to widespread adoption of Java 8 language features, in the upgrade page. -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Member at The Apache Software Foundation Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail http://home.apache.org/~ilgrosso/
RE: Apache Syncope version 2.1 findings
Hi, I found the solution. It was just to alter the table act_re_procdef and change the engine_version_ column to v6but maybe it could be a could thing during installation time to check this. Regards, Mikael Mikael Ekblom IT-Service manager Arcada, IT Jan-Magnus Janssons plats 1, FIN-00560 Helsingfors, Finland TFn: +358 207 699 467 Mobil: +358 207 699 467 From: Mikael Ekblom [mailto:mikael.ekb...@arcada.fi] Sent: tiistai 10. heinäkuuta 2018 18.09 To: user@syncope.apache.org Subject: Apache Syncope version 2.1 findings Hi, I have now tested the 2.1 version or let us say that the installation procedure was tested. My installation path was from 2.0.9. My findings are the following: 1. I had the same regarding the Junit version error message regarding syncope console, but I did not delete the junit dependency in the console pom-file. I just added the version information as 4.8.1 dummy value and it went through. 2. The database script generated the required sql-file as expected, but I had to manually run most of it to double check that i got all the relations and indexes set. I noted during this process that the table ownership was changed from syncope to the default postgres DBA user, so I had to change this manually. This was for the new relations that were created through the sql scipt file. Easily fixed though. 3. The core is not so keen on starting...:) The rest is up and running (enduser and syncope-console) but not the core. The log claims the following: * 17:31:00.300 ERROR org.flowable.engine.impl.cmd.ValidateV5EntitiesCmd - Found v5 process definitions that are the latest version. Enable the 'flowable5CompatibilityEnabled' property in the process engine configuration and make sure the flowable5-compatibility dependency is available on the classpath 17:31:00.304 ERROR org.flowable.engine.impl.cmd.ValidateV5EntitiesCmd - Found v5 process definition with id: userWorkflow:61:5012291, and key: userWorkflow 1. I hope that I do not have to recreate every user due to this error...:) Regarding number 3: can I somehow affect this during run time within workflow.properties or must it be done within the source and the corresponding xml configuration for flowable itself? The flowable engine has not been in use here before. I just do not find out right now where this configuration change should go? Otherwise...all my own customization did compile for version 2.1 also after some modifications. Optional seems to be in pretty heavy use:) More has been packed into interfaces. I just need to get the core started...:) Regards, Mikael
Apache Syncope version 2.1 findings
Hi, I have now tested the 2.1 version or let us say that the installation procedure was tested. My installation path was from 2.0.9. My findings are the following: 1. I had the same regarding the Junit version error message regarding syncope console, but I did not delete the junit dependency in the console pom-file. I just added the version information as 4.8.1 dummy value and it went through. 2. The database script generated the required sql-file as expected, but I had to manually run most of it to double check that i got all the relations and indexes set. I noted during this process that the table ownership was changed from syncope to the default postgres DBA user, so I had to change this manually. This was for the new relations that were created through the sql scipt file. Easily fixed though. 3. The core is not so keen on starting...:) The rest is up and running (enduser and syncope-console) but not the core. The log claims the following: * 17:31:00.300 ERROR org.flowable.engine.impl.cmd.ValidateV5EntitiesCmd - Found v5 process definitions that are the latest version. Enable the 'flowable5CompatibilityEnabled' property in the process engine configuration and make sure the flowable5-compatibility dependency is available on the classpath 17:31:00.304 ERROR org.flowable.engine.impl.cmd.ValidateV5EntitiesCmd - Found v5 process definition with id: userWorkflow:61:5012291, and key: userWorkflow 4. I hope that I do not have to recreate every user due to this error...:) Regarding number 3: can I somehow affect this during run time within workflow.properties or must it be done within the source and the corresponding xml configuration for flowable itself? The flowable engine has not been in use here before. I just do not find out right now where this configuration change should go? Otherwise...all my own customization did compile for version 2.1 also after some modifications. Optional seems to be in pretty heavy use:) More has been packed into interfaces. I just need to get the core started...:) Regards, Mikael
Pull task template and assignment of role failure
Hi, Can anyone else confirm, that when a template is associated with a pull task and within that template definition a role is to be assigned to the user automatically, the role itself does not show up for the user just created and pulled from the connector through that specific pull action? The role assignment is omitted. Everything else works. That just happened to us here. Regards, Mikael Mikael Ekblom IT-Service manager Arcada, IT Jan-Magnus Janssons plats 1, FIN-00560 Helsingfors, Finland TFn: +358 207 699 467 Mobil: +358 207 699 467
Syncope setup towards ADFS 3.0
Hi, A short practical question: have anyone at Tirasa or someone else tried to use ADFS with Syncope for the SSO? Any additional experiences from this would be appreciated to maybe save time over here. I'm about to set up this now and will try to gather information along the way for future use. It did not just go through out of the box and I'm not sure now what is going on (ADFS let the request through) but Syncope still claims SAML token security failure, so I'll need to dissect the source code a bit. Regards, Mikael Mikael Ekblom IT-Service manager Arcada, IT Jan-Magnus Janssons plats 1, FIN-00560 Helsingfors, Finland TFn: +358 207 699 467 Mobil: +358 207 699 467
RE: Issue SYNCOPE-1235 dynamic group memberships
Hi, Now when you mention it, you are right! It is when you have a group with an already assigned external resource and link another external resource to the same group that the dynamic membership ruleset is voided. So the scenario is different. OK, good to hear that you also confirmed the same bug. Mikael Ekblom IT-Service manager Arcada, IT Jan-Magnus Janssons plats 1, FIN-00560 Helsingfors, Finland TFn: +358 207 699 467 Mobil: +358 207 699 467 From: Andrea Patricelli [mailto:andreapatrice...@apache.org] Sent: tiistai 13. helmikuuta 2018 16.37 To: user@syncope.apache.org Subject: Re: Issue SYNCOPE-1235 dynamic group memberships Hi Mikael, I made a check. I confirm you that there is a bug about dynamic memberhsip conditions. But I've been experiencing a bit different behavior: the dynamic membership conditions are voided after assigning or linking the resource to the group. I've not experienced the viceversa, i.e. your problem and what is exposed in SYNCOPE-1235. BTW I've opened [1]. Best regards, Andrea [1] https://issues.apache.org/jira/browse/SYNCOPE-1276 Il 12/02/2018 16:24, Mikael Ekblom ha scritto: Hi, Issue SYNCOPE-1235 I’m sorry to be a party pooper, but this issue with disappearing dynamic group memberships happened to us now again when de unassigned an external resource from a group. Are you sure that it is 100 % fixed? The scenario was as before: unassign an external resource from the group-> no more dynamic memberships and the memberships also. Fortunately, this was for a smaller subproject, but this could potentially be disastrous for us if people suddenly get unassigned from groups and the resource assignments also disappears. This should be a clean 2.0.7-version that I’m testing it on. Regards, Mikael Mikael Ekblom IT-Service manager Arcada, IT Jan-Magnus Janssons plats 1, FIN-00560 Helsingfors, Finland TFn: +358 207 699 467 Mobil: +358 207 699 467 From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: keskiviikko 15. marraskuuta 2017 10.21 To: user@syncope.apache.org<mailto:user@syncope.apache.org> Subject: Re: Question regarding resource assignment through groups Hi Mikael, bug confirmed: https://issues.apache.org/jira/browse/SYNCOPE-1235 Thanks for reporting. Regards. On 07/11/2017 13:45, Mikael Ekblom wrote: Hi, Now I got it reproduced. I created a group arcadaTest and assigned this group to a resource, resource-testdb within your test environment. Everything went smooth. After that, I then went via the logical interface/user interface and performed an unlink of the assigned resource from the arcadaTest group. When I edited the group itself after that operation, I noticed that the dynamic rule was gone. Maybe I could see some logic to that, but then again maybe not…☺ I think that group membership dynamic rules should be preserved even though we are un-assigning a resource? Regards, Mikael Mikael Ekblom System developer Arcada, IT Jan-Magnus Janssons plats 1, FIN-00560 Helsingfors, Finland TFn: +358 207 699 467 Mobil: +358 207 699 467 From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: torstai 2. marraskuuta 2017 15.26 To: user@syncope.apache.org<mailto:user@syncope.apache.org> Subject: Re: Question regarding resource assignment through groups On 01/11/2017 10:34, Mikael Ekblom wrote: Hi, We are quite close now to the actual deployment of our solution based on Syncope. It has been quite a search for the right implementations. Hi Mikael, nice to hear that. I'd recommend to stay in touch with upgrades and ensure to always run the latest 2.0.X version. Anyhow, I noticed that if you had assigned an external resource to a group for provision purposes and then removed this same resource again from the assigned group, then the dynamic rules for the group membership were also removed at the same time. We were quite surprised by this when we saw very different results between runs and noticed that well, users were not part of that group anymore and thus not assigned to the external resource as a consequence of that. Is this really part of the implementation as a reaction to the change of assigned external resources? Could you please summarize with a concrete example? Or, if possible, attempt to reproduce the problem via http://syncope-vm.apache.org:9080/syncope-console/ ? Thanks. Regards. -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Member at The Apache Software Foundation Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail http://home.apache.org/~ilgrosso/<http://home.apache.org/%7Eilgrosso/> -- Dott. Andrea Patricelli Tel. +39 3204524292 Developer @ Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39 085973 http://www.tirasa.net Apache Syncope PMC Member
RE: Question regarding upcoming PullAction changes in version 2.0.7
Hi, Good to hear that we follow standards!...:) Regards, Mikael Mikael Ekblom System developer Arcada, IT Jan-Magnus Janssons plats 1, FIN-00560 Helsingfors, Finland TFn: +358 207 699 467 Mobil: +358 207 699 467 From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: torstai 7. joulukuuta 2017 11.40 To: user@syncope.apache.org Subject: Re: Question regarding upcoming PullAction changes in version 2.0.7 Hi Mikael, using pullUtils to get internal matches (if found) is exactly the best-practice for preprocess() to get internal data, congrats :-) Regards. On 07/12/2017 09:10, Mikael Ekblom wrote: Hi, Thank you for the answer. Yes, I found the SyndDeltaBuilder when I was looking around. The thing was more ,that I needed the current internal entity information together with the syncdelta due to the fact that the contents of the syncdelta (in our case )should be determined by the roles currently assigned to the user at the time we retrieve the SyncDelta through the connector. In that sense, the 2.0.6 version was more straightforward or maybe easier to use, but I do see your point here…☺ Anyhow, I decided to use the pullutil to get the current user that matched the syncdelta uid to get the currently assigned roles and it seems to work. I then just as you said rebuilt the syncdelta accordingly via the SyncDeltaBuilder. Regards, Mikael Mikael Ekblom System developer Arcada, IT Jan-Magnus Janssons plats 1, FIN-00560 Helsingfors, Finland TFn: +358 207 699 467 Mobil: +358 207 699 467 From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: tiistai 5. joulukuuta 2017 10.08 To: user@syncope.apache.org<mailto:user@syncope.apache.org> Subject: Re: Question regarding upcoming PullAction changes in version 2.0.7 Hi Mikael, the SyncDelta processing was modified by SYNCOPE-1234 [1]. The new preprocess() method is invoked before any other method of the provided implementation, giving clear chance to alter the data coming from underlying resource prior to any other Syncope-side consideration. Before [1] the logic was not adequate as the internal matching logic [3] could not be influenced by PullActions. You have already discovered that SyncDelta instances are immutable; what you are currently missing is that you can use SyncDeltaBuilder [4] to generate new SyncDelta instances. HTH Regards. [1] https://issues.apache.org/jira/browse/SYNCOPE-1234 [2] https://github.com/apache/syncope/blob/2_0_X/core/provisioning-api/src/main/java/org/apache/syncope/core/provisioning/api/pushpull/PullActions.java#L40 [3] https://github.com/apache/syncope/blob/2_0_X/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/pushpull/AbstractPullResultHandler.java#L741 [4] http://connid.tirasa.net/apidocs/1.4/org/identityconnectors/framework/common/objects/SyncDeltaBuilder.html On 04/12/2017 16:40, Mikael Ekblom wrote: Hi, I have one question: in version 2.0.7 I have noticed that you have added a preprocess function to the default pull actions class. We would like to alter the syncdelta in certain cases ie the user should be kept as enabled (ie. __ENABLED__ set to true) as the user can have two different roles simultaneously and one primary role should be kept even though if the user is seen to have lost one primary role in the case that the user (as an example) has graduated and has been archived within the study register (__ENABLED__ set to false within the connector in this case) + we get a match for the user and this archive. We get a match, but the user should be set to active. Arcada do not deprovision the users directly either if an entity matches an archived version for a specific master source. The user might still have a role as staff or employee and the syncdelta should be set to __ENABLE__=true in this particular case but the rest of the roles bound to the student role should be removed. This could be done in 2.0.6 within the beforeupdate function also, that in version 2.0.6 returned the SyncDelta but in version 2.0.7 the same function returns void. How is this supposed to work in the new implementation in 2.0.7 when you do not have the user information (or entity together with role information) available directly within the current function and syncdelta scope within preprocess? The SyncDelta object just has an read-only map of the current syncdelta attributes as far as I have seen if you try to alter the attributes within beforeupdate, so it seems to be too late for that there. You basically have to look up the user through the __UID__ I guess within preprocess, but through which function and through which library? What is the best option you have in this case? It is enough if you have a hint to give and I’ll find the rest. I hope this text is somehow understandable! Regards, Mikael -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Member at The Apache So
RE: Question regarding upcoming PullAction changes in version 2.0.7
Hi, Thank you for the answer. Yes, I found the SyndDeltaBuilder when I was looking around. The thing was more ,that I needed the current internal entity information together with the syncdelta due to the fact that the contents of the syncdelta (in our case )should be determined by the roles currently assigned to the user at the time we retrieve the SyncDelta through the connector. In that sense, the 2.0.6 version was more straightforward or maybe easier to use, but I do see your point here…☺ Anyhow, I decided to use the pullutil to get the current user that matched the syncdelta uid to get the currently assigned roles and it seems to work. I then just as you said rebuilt the syncdelta accordingly via the SyncDeltaBuilder. Regards, Mikael Mikael Ekblom System developer Arcada, IT Jan-Magnus Janssons plats 1, FIN-00560 Helsingfors, Finland TFn: +358 207 699 467 Mobil: +358 207 699 467 From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: tiistai 5. joulukuuta 2017 10.08 To: user@syncope.apache.org Subject: Re: Question regarding upcoming PullAction changes in version 2.0.7 Hi Mikael, the SyncDelta processing was modified by SYNCOPE-1234 [1]. The new preprocess() method is invoked before any other method of the provided implementation, giving clear chance to alter the data coming from underlying resource prior to any other Syncope-side consideration. Before [1] the logic was not adequate as the internal matching logic [3] could not be influenced by PullActions. You have already discovered that SyncDelta instances are immutable; what you are currently missing is that you can use SyncDeltaBuilder [4] to generate new SyncDelta instances. HTH Regards. [1] https://issues.apache.org/jira/browse/SYNCOPE-1234 [2] https://github.com/apache/syncope/blob/2_0_X/core/provisioning-api/src/main/java/org/apache/syncope/core/provisioning/api/pushpull/PullActions.java#L40 [3] https://github.com/apache/syncope/blob/2_0_X/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/pushpull/AbstractPullResultHandler.java#L741 [4] http://connid.tirasa.net/apidocs/1.4/org/identityconnectors/framework/common/objects/SyncDeltaBuilder.html On 04/12/2017 16:40, Mikael Ekblom wrote: Hi, I have one question: in version 2.0.7 I have noticed that you have added a preprocess function to the default pull actions class. We would like to alter the syncdelta in certain cases ie the user should be kept as enabled (ie. __ENABLED__ set to true) as the user can have two different roles simultaneously and one primary role should be kept even though if the user is seen to have lost one primary role in the case that the user (as an example) has graduated and has been archived within the study register (__ENABLED__ set to false within the connector in this case) + we get a match for the user and this archive. We get a match, but the user should be set to active. Arcada do not deprovision the users directly either if an entity matches an archived version for a specific master source. The user might still have a role as staff or employee and the syncdelta should be set to __ENABLE__=true in this particular case but the rest of the roles bound to the student role should be removed. This could be done in 2.0.6 within the beforeupdate function also, that in version 2.0.6 returned the SyncDelta but in version 2.0.7 the same function returns void. How is this supposed to work in the new implementation in 2.0.7 when you do not have the user information (or entity together with role information) available directly within the current function and syncdelta scope within preprocess? The SyncDelta object just has an read-only map of the current syncdelta attributes as far as I have seen if you try to alter the attributes within beforeupdate, so it seems to be too late for that there. You basically have to look up the user through the __UID__ I guess within preprocess, but through which function and through which library? What is the best option you have in this case? It is enough if you have a hint to give and I’ll find the rest. I hope this text is somehow understandable! Regards, Mikael -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Member at The Apache Software Foundation Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail http://home.apache.org/~ilgrosso/
Question regarding upcoming PullAction changes in version 2.0.7
Hi, I have one question: in version 2.0.7 I have noticed that you have added a preprocess function to the default pull actions class. We would like to alter the syncdelta in certain cases ie the user should be kept as enabled (ie. __ENABLED__ set to true) as the user can have two different roles simultaneously and one primary role should be kept even though if the user is seen to have lost one primary role in the case that the user (as an example) has graduated and has been archived within the study register (__ENABLED__ set to false within the connector in this case) + we get a match for the user and this archive. We get a match, but the user should be set to active. Arcada do not deprovision the users directly either if an entity matches an archived version for a specific master source. The user might still have a role as staff or employee and the syncdelta should be set to __ENABLE__=true in this particular case but the rest of the roles bound to the student role should be removed. This could be done in 2.0.6 within the beforeupdate function also, that in version 2.0.6 returned the SyncDelta but in version 2.0.7 the same function returns void. How is this supposed to work in the new implementation in 2.0.7 when you do not have the user information (or entity together with role information) available directly within the current function and syncdelta scope within preprocess? The SyncDelta object just has an read-only map of the current syncdelta attributes as far as I have seen if you try to alter the attributes within beforeupdate, so it seems to be too late for that there. You basically have to look up the user through the __UID__ I guess within preprocess, but through which function and through which library? What is the best option you have in this case? It is enough if you have a hint to give and I'll find the rest. I hope this text is somehow understandable! Regards, Mikael Mikael Ekblom System developer Arcada, IT Jan-Magnus Janssons plats 1, FIN-00560 Helsingfors, Finland TFn: +358 207 699 467 Mobil: +358 207 699 467
RE: Question regarding resource assignment through groups
Hi, Now I got it reproduced. I created a group arcadaTest and assigned this group to a resource, resource-testdb within your test environment. Everything went smooth. After that, I then went via the logical interface/user interface and performed an unlink of the assigned resource from the arcadaTest group. When I edited the group itself after that operation, I noticed that the dynamic rule was gone. Maybe I could see some logic to that, but then again maybe not…☺ I think that group membership dynamic rules should be preserved even though we are un-assigning a resource? Regards, Mikael Mikael Ekblom System developer Arcada, IT Jan-Magnus Janssons plats 1, FIN-00560 Helsingfors, Finland TFn: +358 207 699 467 Mobil: +358 207 699 467 From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: torstai 2. marraskuuta 2017 15.26 To: user@syncope.apache.org Subject: Re: Question regarding resource assignment through groups On 01/11/2017 10:34, Mikael Ekblom wrote: Hi, We are quite close now to the actual deployment of our solution based on Syncope. It has been quite a search for the right implementations. Hi Mikael, nice to hear that. I'd recommend to stay in touch with upgrades and ensure to always run the latest 2.0.X version. Anyhow, I noticed that if you had assigned an external resource to a group for provision purposes and then removed this same resource again from the assigned group, then the dynamic rules for the group membership were also removed at the same time. We were quite surprised by this when we saw very different results between runs and noticed that well, users were not part of that group anymore and thus not assigned to the external resource as a consequence of that. Is this really part of the implementation as a reaction to the change of assigned external resources? Could you please summarize with a concrete example? Or, if possible, attempt to reproduce the problem via http://syncope-vm.apache.org:9080/syncope-console/ ? Thanks. Regards. -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Member at The Apache Software Foundation Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail http://home.apache.org/~ilgrosso/
Question regarding resource assignment through groups
Hi, We are quite close now to the actual deployment of our solution based on Syncope. It has been quite a search for the right implementations. Anyhow, I noticed that if you had assigned an external resource to a group for provision purposes and then removed this same resource again from the assigned group, then the dynamic rules for the group membership were also removed at the same time. We were quite surprised by this when we saw very different results between runs and noticed that well, users were not part of that group anymore and thus not assigned to the external resource as a consequence of that. Is this really part of the implementation as a reaction to the change of assigned external resources? Regards, Mikael Mikael Ekblom Systemutvecklare/System developer Arcada, IT Jan-Magnus Janssons plats 1, FIN-00560 Helsingfors, Finland TFn: +358 207 699 467 Mobil: +358 207 699 467
Exception during provision on resource AD-connector
(DomainTransactionInterceptor.java:64) ~[syncope-core-persistence-jpa-2.0.5.jar:2.0.5] at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) ~[spring-aop-4.3.10.RELEASE.jar:4.3.10.RELEASE] at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:213) ~[spring-aop-4.3.10.RELEASE.jar:4.3.10.RELEASE] at com.sun.proxy.$Proxy295.call(Unknown Source) ~[?:?] at java.util.concurrent.FutureTask.run(Unknown Source) ~[?:1.8.0_121] at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) ~[?:1.8.0_121] at java.util.concurrent.FutureTask.run(Unknown Source) ~[?:1.8.0_121] at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) ~[?:1.8.0_121] at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) ~[?:1.8.0_121] at java.lang.Thread.run(Unknown Source) [?:1.8.0_121] Caused by: org.postgresql.util.PSQLException: This statement has been closed. at org.postgresql.jdbc.PgStatement.checkClosed(PgStatement.java:647) ~[postgresql-42.0.0.jar:42.0.0] at org.postgresql.jdbc.PgStatement.getResultSet(PgStatement.java:580) ~[postgresql-42.0.0.jar:42.0.0] at com.zaxxer.hikari.pool.ProxyStatement.getResultSet(ProxyStatement.java:174) ~[HikariCP-java7-2.4.12.jar:?] at com.zaxxer.hikari.pool.HikariProxyPreparedStatement.getResultSet(HikariProxyPreparedStatement.java) ~[HikariCP-java7-2.4.12.jar:?] at org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.getResultSet(DelegatingPreparedStatement.java:205) ~[openjpa-lib-2.4.2.jar:2.4.2] at org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.getResultSet(DelegatingPreparedStatement.java:203) ~[openjpa-lib-2.4.2.jar:2.4.2] at org.apache.openjpa.jdbc.sql.PostgresDictionary$PostgresPreparedStatement.executeQuery(PostgresDictionary.java:1018) ~[openjpa-jdbc-2.4.2.jar:2.4.2] at org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:268) ~[openjpa-lib-2.4.2.jar:2.4.2] at org.apache.openjpa.jdbc.kernel.JDBCStoreManager$CancelPreparedStatement.executeQuery(JDBCStoreManager.java:1800) ~[openjpa-jdbc-2.4.2.jar:2.4.2] at org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:258) ~[openjpa-lib-2.4.2.jar:2.4.2] at org.apache.openjpa.jdbc.sql.SelectImpl.executeQuery(SelectImpl.java:500) ~[openjpa-jdbc-2.4.2.jar:2.4.2] at org.apache.openjpa.jdbc.sql.SelectImpl.execute(SelectImpl.java:425) ~[openjpa-jdbc-2.4.2.jar:2.4.2] at org.apache.openjpa.jdbc.sql.SelectImpl.execute(SelectImpl.java:392) ~[openjpa-jdbc-2.4.2.jar:2.4.2] at org.apache.openjpa.jdbc.sql.LogicalUnion$UnionSelect.execute(LogicalUnion.java:427) ~[openjpa-jdbc-2.4.2.jar:2.4.2] at org.apache.openjpa.jdbc.sql.LogicalUnion.execute(LogicalUnion.java:230) ~[openjpa-jdbc-2.4.2.jar:2.4.2] at org.apache.openjpa.jdbc.sql.LogicalUnion.execute(LogicalUnion.java:220) ~[openjpa-jdbc-2.4.2.jar:2.4.2] at org.apache.openjpa.jdbc.meta.strats.RelationFieldStrategy.load(RelationFieldStrategy.java:835) ~[openjpa-jdbc-2.4.2.jar:2.4.2] at org.apache.openjpa.jdbc.meta.FieldMapping.load(FieldMapping.java:936) ~[openjpa-jdbc-2.4.2.jar:2.4.2] at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:680) ~[openjpa-jdbc-2.4.2.jar:2.4.2] ... 32 more Regards, Mikael Mikael Ekblom Systemutvecklare/System developer Arcada, IT Jan-Magnus Janssons plats 1, FIN-00560 Helsingfors, Finland TFn: +358 207 699 467 Mobil: +358 207 699 467
RE: User username modification during/after a logic action
Hi, I did yes and I tried to double check that specific part, but I have it working now by modifying the parameter types of the parameters that I am passing to my utility functions and the utility class, so basically all is fine for now! Thank you for the response though! Regards, Mikael -Original Message- From: Matteo Alessandroni [mailto:skylar...@apache.org] Sent: torstai 14. syyskuuta 2017 11.35 To: user@syncope.apache.org Subject: Re: User username modification during/after a logic action Hi Mikael, it seems to be a problem with the "@Transactional" annotation [1]. Did you use it in your code? Regards, Matteo [1] https://docs.spring.io/spring/docs/current/spring-framework-reference/html/transaction.html#transaction-declarative-annotations On 2017-08-30 16:54, Mikael Ekblom <mikael.ekb...@arcada.fi> wrote: > Hi, > > We have the following scenario: we have some users that are not as per see > associated with our organization. They are called UFO-members. Now, we create > these through an manual process that I will now try to implement in Syncope > too. It has been outside everything so far. > > When we create these users through the syncope console, I have noticed that > we get the key for the recently created user through the logic actions. The > thing now is, that the users using syncope and the console will be pretty > lazy and would like to have the username created automatically according to > the same automated standard as the rest via the firstname + lastname > combination > > You can set the username via the console and Syncope will report if the > username is already in use. I’d like to automate this and check for myself > in the background if the current username is in use and within the > repository. If found, we will try another iterated combination. We do the > same when we pull users from external resources. > > Now, within the logic action I have the possibility to search via the key for > the UserTO object though UserDAO. But, if I call for UserDAO.findByUsername() > , I get that “EntityManager not found for the Master domainâ€. I guess it > is not available within the scope and thus when a combination of a username > is created, I do not get to check the validity for the new combination for > the username itself. > > This is the first time I encountered this problem and I wonder if you there > have a quick answer regarding how to search for a specific username and not > the key during a logic action? > > Regards, > > Mikael > > > >
User username modification during/after a logic action
Hi, We have the following scenario: we have some users that are not as per see associated with our organization. They are called UFO-members. Now, we create these through an manual process that I will now try to implement in Syncope too. It has been outside everything so far. When we create these users through the syncope console, I have noticed that we get the key for the recently created user through the logic actions. The thing now is, that the users using syncope and the console will be pretty lazy and would like to have the username created automatically according to the same automated standard as the rest via the firstname + lastname combination You can set the username via the console and Syncope will report if the username is already in use. I’d like to automate this and check for myself in the background if the current username is in use and within the repository. If found, we will try another iterated combination. We do the same when we pull users from external resources. Now, within the logic action I have the possibility to search via the key for the UserTO object though UserDAO. But, if I call for UserDAO.findByUsername() , I get that “EntityManager not found for the Master domain”. I guess it is not available within the scope and thus when a combination of a username is created, I do not get to check the validity for the new combination for the username itself. This is the first time I encountered this problem and I wonder if you there have a quick answer regarding how to search for a specific username and not the key during a logic action? Regards, Mikael
RE: Adding a UPLainAttribute during after> recomemnded way
Hi, Never mind, I think I found the best solution to this question. We do make it unnecessarily complicated by doing this but it works…☺ Regards, Mikael From: Mikael Ekblom [mailto:mikael.ekb...@arcada.fi] Sent: keskiviikko 2. elokuuta 2017 14.32 To: user@syncope.apache.org Subject: Adding a UPLainAttribute during after> recomemnded way Hi, We need to add a mailroutingattribute during user pull. The mailrouting attribute might have one of three different values, depending on the role the user has within the organization. DO not ask me why, but for some reasons this is the way it is for historical reasons. I can see that we must implement this after the provisioning has been done. The beforeProvision has not reacted to the role change when the user is created. beforeUpdate will not do it either in a timely fashion. We have the final state after these operations. So, what is the cleanest way to do this via the DAO or to add an UPLainAttribute to an existing user and save the same? Regards, Mikael
Adding a UPLainAttribute during after> recomemnded way
Hi, We need to add a mailroutingattribute during user pull. The mailrouting attribute might have one of three different values, depending on the role the user has within the organization. DO not ask me why, but for some reasons this is the way it is for historical reasons. I can see that we must implement this after the provisioning has been done. The beforeProvision has not reacted to the role change when the user is created. beforeUpdate will not do it either in a timely fashion. We have the final state after these operations. So, what is the cleanest way to do this via the DAO or to add an UPLainAttribute to an existing user and save the same? Regards, Mikael
RE: DefaultLogicActions and pull
Hi, Yeah, I had them there. I somehow guessed that this is the case and I’ll just have to move them back then…☺ Regards, Mikael From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: tiistai 1. elokuuta 2017 17.15 To: user@syncope.apache.org Subject: Re: DefaultLogicActions and pull On 01/08/2017 16:07, Mikael Ekblom wrote: Hi, I have tried to move some related logic for the whole realm to the DefaultLogicActions-implementation within our Syncope. Now though I can see that during the pull and the subsequent creation of the users, the defaultlogicaction beforeCreate, afterCreate etc. will never be triggered during actual pull and the subsequent creation. Updates after the pull (if a field changes) do trigger the suitable functions (beforeUpdate, afterupdate etc. ). The action is specified for the realm, where I put the users during the pull. No error messages or anything indication a serious problem. Am I missing something or should it just not be possible to do? I think the sync process should generate a create request towards the core at some point even if you pull the information from an external source? Hi Mikael, LogicActions are triggered when the Logic layer is involved, e.g. during REST calls. https://syncope.apache.org/docs/reference-guide.html#overview If you need to perform custom tasks during pull, use PullActions. HTH Regards. -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Member at The Apache Software Foundation Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail http://home.apache.org/~ilgrosso/
RE: Wrong rest url
Hi, A small hint: check the console.properties file and the setting there. Make sure that they adhere to the general Tomcat instance host configuration ie. check the host name and port within that file. Should be found either within the webapps/WEB-INF/classes-directory or within the directory you specified while creating the maven project. Regards, Mikael From: Dino Mifsud [mailto:dinomifsu...@gmail.com] Sent: tiistai 25. heinäkuuta 2017 20.02 To: user@syncope.apache.org Subject: Wrong rest url Hi I am trying to deploy Syncope with maven. I have done changes and build = the project with maven. I copied the war files to a local tomcat = instance running on port 8080. When I try to access syncope-console I = get an error with session. In the tomcat logs it seems that the syncope-console is trying to access = the rest api of syncope on port 9080 instead of 8080. See the logs below Can you help me solve the issue please? Thanks Caused by: javax.ws.rs.ProcessingException: java.net.ConnectException: = ConnectException invoking http://localhost:9080/syncope/rest/platform: = Connection refused at = org.apache.cxf.jaxrs.client.AbstractClient.checkClientException(AbstractCl= ient.java:604) at = org.apache.cxf.jaxrs.client.AbstractClient.preProcessResult(AbstractClient= .java:580) at = org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProx= yImpl.java:785) at = org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:23= 5) at com.sun.proxy.$Proxy232.platform(Unknown Source) at = org.apache.syncope.client.console.SyncopeConsoleSession.(SyncopeCons= oleSession.java:108)
RE: Pull users from two primary sources with different UID:s
Hi, Well, I totally forgot about that one…that truly simplified this case and I did not have to re-invent the wheel again! I thank thee for that!...:) Even though the attributes left to correlate with are a bit ambiguous and we do have data quality problems here… Regards, Mikael From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: torstai 15. kesäkuuta 2017 18.03 To: user@syncope.apache.org Subject: Re: Pull users from two primary sources with different UID:s Hi Mikael, if I understand your environment, the problem can be seen as the general situation where there are two distinct external resources, each with a different unique id, matching two distinct attributes in Syncope. In such situations, at least one of the resources bears one or more attributes that can be used to match users on Syncope, even if the key is not (yet) available (say Firstname + Surname, even though I know I am over-simplifying). The tool to leverage here are the Pull Policies [1], in particular the Pull Correlation Rules [2]. HTH Regards. [1] https://syncope.apache.org/docs/reference-guide.html#policies-pull [2] https://syncope.apache.org/docs/reference-guide.html#pull-correlation-rules On 14/06/2017 16:05, Mikael Ekblom wrote: Hi, We have a small challenge here that includes two primary pull sources, where the UID for these sources are not the same or cannot be set to the same value. The only common UID(National Identification Number) that could be used as a kind of primary key for users pulled from both sources (that would make this an easy case) can change to my surprise when it comes to foreign exchange students.This is when they get Finnish versions of the NIN. It will not be possible to set any previousUID column to both sources either (for payroll particularly) and I would like to avoid having to build any separate repository only due to this case. So, what I do during provision and within beforeProvision to be precise, is that I check if I get any existing match for the pulled user based on the NIN. If I do, I like to create a new syndelta with the information from the existing user together with the fields that should be added. If no match is found, then the provisioning should continue as before. What I do is to create a new syncdelta with the UID changed to the existing UID for the account matching, set the connector object with the required fields, create an AnyTO object and an anyPatch object and send this to beforeupdate together with the new delta. Everything is fine so far. Within beforeUpdate, I can see that I get all the required fields for that connector object. AbstractAnyDataBinder though claims that I have a required attribute missing: eduPersonUniqueId, that I can see that is present within both objects (AnyTO and AnyPatch ) sent to the beforeUpdate and it is also available as a field within the connector object for the sync delta. What am I missing? Should I recreate the syncdelta object again within beforeUpdate together with the AnyTO and AnyPatch objects too, to be sure? What is required for beforeUpdate to function properly? Is it even possible to revert to beforeUpdate from say beforeProvision if a possible match is found? It should I think. It is a bit troublesome to check for yourself, when the API-documentation is not that detailed…☺ Regards, Mikael -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Member at The Apache Software Foundation Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail http://home.apache.org/~ilgrosso/
RE: cmd bundle framework filter bundle
Hi,
Yeah, I traced it to the connID framework. I think though that we will manage
without this part for now. We encountered other challenges!
Regards,
Mikael
From: Francesco Chicchiriccò [mailto:ilgros...@apache.org]
Sent: maanantai 5. kesäkuuta 2017 18.00
To: user@syncope.apache.org
Subject: Re: cmd bundle framework filter bundle
On 31/05/2017 10:16, Mikael Ekblom wrote:
Hi,
I need to ask you at Tirasa too, that have you seen this error regarding the
cmd bundle and powershell?
java.lang.IllegalStateException: Object {Uid=Attribute: {Name=__UID__,
Value=[backsee1]}, ObjectClass=ObjectClass: __ACCOUNT__, Attributes=[Attribute:
{Name=uid, Value=[x]}, Attribute: {Name=personnr, Value=[1029]}, Attribute:
{Name=__NAME__, Value=[1029]}, Attribute: {Name=__UID__, Value=[]},
Attribute: {Name=__ENABLE__, Value=[true]}], Name=Attribute: {Name=__NAME__,
Value=[1029]}} was returned by by the connector but failed to pass the
framework filter. This seems like wrong implementation of the filter in the
connector.
I guess syncope sees these as regular strings. Searching goes fine, no problem
there. All attributes can be viewed. But when you try to create, then s-t hits
the fan. I have tested both the 0.2 version of the cmd bundle and I’m testing
the 0.3-snapshot version also and I’m modifying the 0.3-version for
troubleshooting purposes.
Both the 0.2-version and the 0.3-snapshot version gives the same result. Maybe
I need to make my own version of execute sequence…☺
Hi Mikael,
the exception above comes from [1], e.g. from the ConnId framework rather than
the ConnId CMD bundle.
You need to provide more details about the error (e.g. longer stacktraces) in
order to understand exactly which ConnId filter - which is set by Syncope code
- is not allowing some search results to pass.
Regards.
[1]
https://github.com/Tirasa/ConnId/blob/master/java/connector-framework-internal/src/main/java/org/identityconnectors/framework/impl/api/local/operations/FilteredResultsHandler.java#L82-L84
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
cmd bundle framework filter bundle
Hi,
I need to ask you at Tirasa too, that have you seen this error regarding the
cmd bundle and powershell?
java.lang.IllegalStateException: Object {Uid=Attribute: {Name=__UID__,
Value=[backsee1]}, ObjectClass=ObjectClass: __ACCOUNT__, Attributes=[Attribute:
{Name=uid, Value=[x]}, Attribute: {Name=personnr, Value=[1029]}, Attribute:
{Name=__NAME__, Value=[1029]}, Attribute: {Name=__UID__, Value=[]},
Attribute: {Name=__ENABLE__, Value=[true]}], Name=Attribute: {Name=__NAME__,
Value=[1029]}} was returned by by the connector but failed to pass the
framework filter. This seems like wrong implementation of the filter in the
connector.
I guess syncope sees these as regular strings. Searching goes fine, no problem
there. All attributes can be viewed. But when you try to create, then s-t hits
the fan. I have tested both the 0.2 version of the cmd bundle and I'm testing
the 0.3-snapshot version also and I'm modifying the 0.3-version for
troubleshooting purposes.
Both the 0.2-version and the 0.3-snapshot version gives the same result. Maybe
I need to make my own version of execute sequence...:)
Regards,
Mikael
Mikael Ekblom
Systemutvecklare/System developer
Arcada, IT
Jan-Magnus Janssons plats 1,
FIN-00560 Helsingfors,
Finland
TFn: +358 207 699 467
Mobil: +358 207 699 467
Dynamic assignment of users to groups-> propagation to AD
Hi, I'll ask a small question here, before I start to implement my own action. We have most of the basic functionality working now (automatic user name creation and password assignments etc. ) and through the template functionality for the external resources able to assign users to basic groups within Syncope and propagate these group memberships to AD too while pulling users from the external HR resource etc. My question though regards dynamic assignments of users to groups based on an attribute for example. This works fine internally and the users are assigned to a group dynamically based on an existing cost center attribute value in the HR system, but those minor changes are not propagated towards AD as a change within the memberships for that group object. By this I mean that the group in AD is still empty, while the console shows that the membership is there within Synope as a dynamic group membership. As for a resource, you have the propagation actions for provisioning users like the ldapmembership, ldappassword etc. and these seem to work pretty much out if the box when you assign "regular" group memberships during a pull. A change in the user will trigger a propagation action towards the external AD resource. But the dynamic assignment of groups do not seem to propagate as I thought that it maybe could. So, I guess that assigning dynamic memberships according to some cost center value during an initial pull, will not trigger a group membership propagation action automatically towards AD for that group object? Is Syncope even designed for that? I guess we need to assign groups through a pull action for the cost center part during update, because the group membership will change through time though during updates? Not a big job either, but I decided to ask just in case. It would be cleaner to have it done as a standard configuration change from the console or maybe added as a feature. Regards, Mikael Mikael Ekblom Systemutvecklare/System developer Arcada, IT Jan-Magnus Janssons plats 1, FIN-00560 Helsingfors, Finland TFn: +358 207 699 467 Mobil: +358 207 699 467
RE: Scripted SQL resource
Hi,
Never mind, I found it. The groovy-script did not like the fact that the
columns within the external db resource had different names than the attributes
internally defined to be mapped for the user class itself.
I solved it by aliasing the columns from the external db within the query
itself to match the provisioning rule.
Regards,
Mikael
From: Mikael Ekblom [mailto:mikael.ekb...@arcada.fi]
Sent: torstai 4. toukokuuta 2017 16.51
To: user@syncope.apache.org
Subject: Scripted SQL resource
Hi,
We have a scripted sql resource set up to fetch data from our HR system. SEARCH
and SYNC capabilities set. Now, as the lines tells us below, the search is
returning values to the it-parameter set within the groovy sql eachRow command
and its closure. The result array seems to be populated.
16:17:02.952 DEBUG Enter: {Uid=Attribute: {Name=__UID__, Value=[4377]},
ObjectClass=ObjectClass: __ACCOUNT__, Attributes=[Attribute: {Name=Efternamn,
Value=[Caspar Klaus Sönvis]}, Attribute: {Name=Fornamn, Value=[Berntzen]},
Attribute: {Name=__NAME__, Value=[4377]}, Attribute: {Name=__UID__,
Value=[4377]}, Attribute: {Name=__ENABLE__, Value=[true]}], Name=Attribute:
{Name=__NAME__, Value=[4377]}}Method: handle
16:17:02.952 DEBUG Return: false Method: handle
But, this is not the case when we try to search and sync from this resource.
When we do a "Explore" through the resource and try to view the contents for
this particular connector, only the pre-defined attributes __UID__,__NAME__ and
__ENABLE__ are visible. The rest of the attributes we set to provision are not
visible for some reason. I attached an example of this as a .png.
The attributes Efternamn and Fornamn should also be visible but no.
As the log states, it seems to state that Return: false. Any pullactionhandler
that we have created will confirm that this operation will not return anything
but the __UID__,__NAME__ and __ENABLE__
. As such we cannot build the usernames accordingly only via this information.
When we connect to this same resource with a dbtable-configuration everything
is mapping fine... This will not work in this case though. I first thought that
do I now have some ISO-8859-1 conversion issue, but this seems not to be the
case. Not for the Dbtable-resource at least.
Another scripted SQL groovy resource towards the same SQL-server and thus we
use the same scripted sql bundle version. I set the fetched __UID__values a bit
differently
16:21:01.956 DEBUG Enter: {Uid=Attribute: {Name=__UID__, Value=[170776-]},
ObjectClass=ObjectClass: __ACCOUNT__, Attributes=[Attribute: {Name=Ort,
Value=[Sibbo]}, Attribute: {Name=efternamn, Value=[Ekblom]}, Attribute:
{Name=fornamn, Value=[Mikael]}, Attribute: {Name=Adress, Value=[xx]},
Attribute: {Name=__NAME__, Value=[170776-xxx]}, Attribute: {Name=__UID__,
Value=[170776-]}, Attribute: {Name=__ENABLE__, Value=[true]}, Attribute:
{Name=personbeteckning, Value=[170776-]}], Name=Attribute: {Name=__NAME__,
Value=[170776-xxx]}}Method: handle
16:21:01.956 DEBUG Return: trueMethod: handle
With a similar scripted sql-resource through groovy, everything is visible from
the built in variables to the other variables stated through the mapping rules.
Column formats are the same.
The big question is: why is the example above stating Return false and the
other, similar one, not? Has anyone seen this before? What makes a scripted
groovy sql resource to return false except for the built in values that must be
there?
At times like these, you wish that you could pay for support...:)
Regards,
Mikael
Mikael Ekblom
Systemutvecklare/System developer
Arcada, IT
Jan-Magnus Janssons plats 1,
FIN-00560 Helsingfors,
Finland
TFn: +358 207 699 467
Mobil: +358 207 699 467
Scripted SQL resource
Hi,
We have a scripted sql resource set up to fetch data from our HR system. SEARCH
and SYNC capabilities set. Now, as the lines tells us below, the search is
returning values to the it-parameter set within the groovy sql eachRow command
and its closure. The result array seems to be populated.
16:17:02.952 DEBUG Enter: {Uid=Attribute: {Name=__UID__, Value=[4377]},
ObjectClass=ObjectClass: __ACCOUNT__, Attributes=[Attribute: {Name=Efternamn,
Value=[Caspar Klaus Sönvis]}, Attribute: {Name=Fornamn, Value=[Berntzen]},
Attribute: {Name=__NAME__, Value=[4377]}, Attribute: {Name=__UID__,
Value=[4377]}, Attribute: {Name=__ENABLE__, Value=[true]}], Name=Attribute:
{Name=__NAME__, Value=[4377]}}Method: handle
16:17:02.952 DEBUG Return: false Method: handle
But, this is not the case when we try to search and sync from this resource.
When we do a "Explore" through the resource and try to view the contents for
this particular connector, only the pre-defined attributes __UID__,__NAME__ and
__ENABLE__ are visible. The rest of the attributes we set to provision are not
visible for some reason. I attached an example of this as a .png.
The attributes Efternamn and Fornamn should also be visible but no.
As the log states, it seems to state that Return: false. Any pullactionhandler
that we have created will confirm that this operation will not return anything
but the __UID__,__NAME__ and __ENABLE__
. As such we cannot build the usernames accordingly only via this information.
When we connect to this same resource with a dbtable-configuration everything
is mapping fine... This will not work in this case though. I first thought that
do I now have some ISO-8859-1 conversion issue, but this seems not to be the
case. Not for the Dbtable-resource at least.
Another scripted SQL groovy resource towards the same SQL-server and thus we
use the same scripted sql bundle version. I set the fetched __UID__values a bit
differently
16:21:01.956 DEBUG Enter: {Uid=Attribute: {Name=__UID__, Value=[170776-]},
ObjectClass=ObjectClass: __ACCOUNT__, Attributes=[Attribute: {Name=Ort,
Value=[Sibbo]}, Attribute: {Name=efternamn, Value=[Ekblom]}, Attribute:
{Name=fornamn, Value=[Mikael]}, Attribute: {Name=Adress, Value=[xx]},
Attribute: {Name=__NAME__, Value=[170776-xxx]}, Attribute: {Name=__UID__,
Value=[170776-]}, Attribute: {Name=__ENABLE__, Value=[true]}, Attribute:
{Name=personbeteckning, Value=[170776-]}], Name=Attribute: {Name=__NAME__,
Value=[170776-xxx]}}Method: handle
16:21:01.956 DEBUG Return: trueMethod: handle
With a similar scripted sql-resource through groovy, everything is visible from
the built in variables to the other variables stated through the mapping rules.
Column formats are the same.
The big question is: why is the example above stating Return false and the
other, similar one, not? Has anyone seen this before? What makes a scripted
groovy sql resource to return false except for the built in values that must be
there?
At times like these, you wish that you could pay for support...:)
Regards,
Mikael
Mikael Ekblom
Systemutvecklare/System developer
Arcada, IT
Jan-Magnus Janssons plats 1,
FIN-00560 Helsingfors,
Finland
TFn: +358 207 699 467
Mobil: +358 207 699 467
RE: Windows server scripted sql + groovy
Hi, Ah yeah, forgot about the pull action interface. That is probably the right place for it. I’ll see what I can do with the office 365 thing. Basically, it is only a system call to a server with office 365 powershell installed. Even connid cmd could be a good start…☺ Regards, Mikael From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: tiistai 4. huhtikuuta 2017 10.44 To: user@syncope.apache.org Subject: Re: Windows server scripted sql + groovy Hi Mikael, see my replies on-line. Regards. On 04/04/2017 09:35, Mikael Ekblom wrote: Hi, Ah, ok. The groovy-all.jar had to be moved into the syncope web-inf lib directory.So now we have two options: local file bundle and through the connid-server. Very well! Another question by the way. We have our HR-system as a cloud solution. It will be configured as an external resource of course. The thing now is that we are used to generate usernames according to an automated solution. We do not use firstname.lastname as the uid or samaccountname format. A recursive function so to speak based on the firstname lastname combination that we get from HR and other duplication checks etc. I cannot see that syncope will manage automated creation of username as for now from an external resource on the fly? Not even through transformations? I 'd say you need to code a PullActions class https://syncope.apache.org/docs/reference-guide.html#pullactions e.g. something that is invoked around your pull task execution, with option to mangle its input / output data. Please be aware that PullActions (as all other customizations) require to start with a Maven project: https://syncope.apache.org/docs/reference-guide.html#customization I think I will need to extend a connector for this task… and then the famous Office365 license thing that I think you had on the table too. Exactly, my personal TODO list keeps growing, though... :-/ From: Marco Di Sabatino Di Diodoro [mailto:marco.disabat...@tirasa.net] Sent: maanantai 3. huhtikuuta 2017 14.31 To: user@syncope.apache.org<mailto:user@syncope.apache.org> Subject: Re: Windows server scripted sql + groovy Hi Il 03/04/2017 12:44, Mikael Ekblom ha scritto: Hi, We or I have been playing around with syncope for a while. I have a question now regarding a scripted sql resource and groovy. What we are trying to achieve here, is to get the student accounts over from our home grown student administration system. The scripted sql connector bundle is available as per definition in the connid.properties file and is also available through the administrative panel. But, the log is complaining about the following: “java.lang.IlegalArgumentException: Language not supported: GROOVY” when the script language is defined. Check if in your connector server instance the groovy-all jar is present. If not, try to copy it from Syncope in the connector server. Regards M Some definition missing? I cannot pinpoint anything based on the documentation. I even tried to install groovy separately on the server itself, but it did not solve the problem. It would help a lot to get this done natively. Otherwise I need to implement another proxy repository for this task. Regards, Mikael -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Member at The Apache Software Foundation Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail http://home.apache.org/~ilgrosso/
RE: Windows server scripted sql + groovy
Hi, Ah, ok. The groovy-all.jar had to be moved into the syncope web-inf lib directory. So now we have two options: local file bundle and through the connid-server. Very well! Another question by the way. We have our HR-system as a cloud solution. It will be configured as an external resource of course. The thing now is that we are used to generate usernames according to an automated solution. We do not use firstname.lastname as the uid or samaccountname format. A recursive function so to speak based on the firstname lastname combination that we get from HR and other duplication checks etc. I cannot see that syncope will manage automated creation of username as for now from an external resource on the fly? Not even through transformations? I think I will need to extend a connector for this task... and then the famous Office365 license thing that I think you had on the table too. Regards, Mikael From: Marco Di Sabatino Di Diodoro [mailto:marco.disabat...@tirasa.net] Sent: maanantai 3. huhtikuuta 2017 14.31 To: user@syncope.apache.org Subject: Re: Windows server scripted sql + groovy Hi Il 03/04/2017 12:44, Mikael Ekblom ha scritto: Hi, We or I have been playing around with syncope for a while. I have a question now regarding a scripted sql resource and groovy. What we are trying to achieve here, is to get the student accounts over from our home grown student administration system. The scripted sql connector bundle is available as per definition in the connid.properties file and is also available through the administrative panel. But, the log is complaining about the following: "java.lang.IlegalArgumentException: Language not supported: GROOVY" when the script language is defined. Check if in your connector server instance the groovy-all jar is present. If not, try to copy it from Syncope in the connector server. Regards M Some definition missing? I cannot pinpoint anything based on the documentation. I even tried to install groovy separately on the server itself, but it did not solve the problem. It would help a lot to get this done natively. Otherwise I need to implement another proxy repository for this task. Regards, Mikael -- Dott. Marco Di Sabatino Di Diodoro Tel. +39 3939065570 Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39 085973 http://www.tirasa.net Apache Syncope PMC Member http://people.apache.org/~mdisabatino/
Windows server scripted sql + groovy
Hi, We or I have been playing around with syncope for a while. I have a question now regarding a scripted sql resource and groovy. What we are trying to achieve here, is to get the student accounts over from our home grown student administration system. The scripted sql connector bundle is available as per definition in the connid.properties file and is also available through the administrative panel. But, the log is complaining about the following: "java.lang.IlegalArgumentException: Language not supported: GROOVY" when the script language is defined. Some definition missing? I cannot pinpoint anything based on the documentation. I even tried to install groovy separately on the server itself, but it did not solve the problem. It would help a lot to get this done natively. Otherwise I need to implement another proxy repository for this task. Regards, Mikael
RE: Creating a virtual schema type ->empty type list
Hi, Sorry, I don't get this last point: FYI, Syncope can be deployed and run in Windows environments too. I was referring to the fact that it might be that we will jump over to deploy Syncope on some Linux-distribution. But as you said, it is deployed already on a Windows server and works fine. What we need to check is how to connect to office365 PowerShell and automatically assign licenses through the IDM if possible. Synchronization with Azure AD should work out of the box through sync with AD -> Azure AD connect , but assigning licenses is something else. This should also be role based. I must see what I can find for that or maybe write my own bundle. Regards, Mikael From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: keskiviikko 1. maaliskuuta 2017 16.30 To: user@syncope.apache.org Subject: Re: Creating a virtual schema type ->empty type list On 01/03/2017 08:29, Mikael Ekblom wrote: Hi, OK, so that was the logic behind it! Now I start to have all the dependencies clear. Tested it and now everything makes sense. That's great to hear. Our deployment is pretty small though. Only 200 + personnel + some 2000 students. But I’ll check the postgress option. The core seems to be configured by default towards the Postgress option. Yes, it is :-) I like the way you can augment Syncope if needed in a strongly typed language. Maybe we’ll even be able to remove the existing php-based “IDM”, which is more of a plain sync engine with no editable business logic capabilities what so ever. Not my production though… It might be that we will end up with a *nix environment in the end. Sorry, I don't get this last point: FYI, Syncope can be deployed and run in Windows environments too. Regards. From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: tiistai 28. helmikuuta 2017 17.54 To: user@syncope.apache.org<mailto:user@syncope.apache.org> Subject: Re: Creating a virtual schema type ->empty type list On 28/02/2017 16:26, Mikael Ekblom wrote: Hi, We are currently evaluating Syncopy as a candidate for our future IDM. Hi, glad to hear that :-) We have some choices on the table and we are even considering writing our own IDM from scratch, but that is something I would like to avoid for practical reasons…☺ I think that would be inventing the wheel again nowadays. Our neighbor Helsinki University is implementing the same solution, so I thought that I will join the community regarding this one. Anyhow, I have a working Syncopy 2.0.2 running on a Windows server 2012 R2 with mysql as the backbone. It is setup and configured via Apache Maven and is running with Tomcat 8.5 as the container. Everything seems to be working. I have managed to create the connector to our AD with the built in/shipped connector. I have also assigned a resource to that connector. Via that resource, we will pull information from our AD as an initial test. The connector reports that it works. Very nice, indeed. One note: while it is perfectly fine for evaluation, I would personally prefer PostgreSQL over MySQL / MariaDB, as some of my customers have been reporting complaints about search performances. We have been constantly providing enhancements and fixes about that, but there have been simply no issues in all the PostgreSQL-based deployments - some of them being very large in numbers. One problem though. I have been able to create all schema types but the virtual one. When I’m supposed to create a virtual schema type for attributes that Syncope will not own and set the ad-resource as the de facto resource, the type drop down list for the virtual schema is empty and just states “Choose one”. What am I missing here? Some schema definition topic missed somewhere? This is not a panic question, as we are just evaluating, but I figure that I might save some time to ask via the mailing list first. I do have my own abstractions to do for our own maybe to come IDM…☺ I am assuming you are using the Admin UI here. If so, you need first to select a Resource (among the ones available) and then the Type combo will be populated with all the provision rules defined for that Resource. Finally, you will need to provide the external attribute to which the new Virtual Schema's attributes will be linked. More details available at: https://syncope.apache.org/docs/reference-guide.html#virtual HTH Regards. -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Member at The Apache Software Foundation Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail http://home.apache.org/~ilgrosso/
RE: Creating a virtual schema type ->empty type list
Hi, OK, so that was the logic behind it! Now I start to have all the dependencies clear. Tested it and now everything makes sense. Our deployment is pretty small though. Only 200 + personnel + some 2000 students. But I’ll check the postgress option. The core seems to be configured by default towards the Postgress option. I like the way you can augment Syncope if needed in a strongly typed language. Maybe we’ll even be able to remove the existing php-based “IDM”, which is more of a plain sync engine with no editable business logic capabilities what so ever. Not my production though… It might be that we will end up with a *nix environment in the end. Thanks a lot! Regards, Mikael From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: tiistai 28. helmikuuta 2017 17.54 To: user@syncope.apache.org Subject: Re: Creating a virtual schema type ->empty type list On 28/02/2017 16:26, Mikael Ekblom wrote: Hi, We are currently evaluating Syncopy as a candidate for our future IDM. Hi, glad to hear that :-) We have some choices on the table and we are even considering writing our own IDM from scratch, but that is something I would like to avoid for practical reasons…☺ I think that would be inventing the wheel again nowadays. Our neighbor Helsinki University is implementing the same solution, so I thought that I will join the community regarding this one. Anyhow, I have a working Syncopy 2.0.2 running on a Windows server 2012 R2 with mysql as the backbone. It is setup and configured via Apache Maven and is running with Tomcat 8.5 as the container. Everything seems to be working. I have managed to create the connector to our AD with the built in/shipped connector. I have also assigned a resource to that connector. Via that resource, we will pull information from our AD as an initial test. The connector reports that it works. Very nice, indeed. One note: while it is perfectly fine for evaluation, I would personally prefer PostgreSQL over MySQL / MariaDB, as some of my customers have been reporting complaints about search performances. We have been constantly providing enhancements and fixes about that, but there have been simply no issues in all the PostgreSQL-based deployments - some of them being very large in numbers. One problem though. I have been able to create all schema types but the virtual one. When I’m supposed to create a virtual schema type for attributes that Syncope will not own and set the ad-resource as the de facto resource, the type drop down list for the virtual schema is empty and just states “Choose one”. What am I missing here? Some schema definition topic missed somewhere? This is not a panic question, as we are just evaluating, but I figure that I might save some time to ask via the mailing list first. I do have my own abstractions to do for our own maybe to come IDM…☺ I am assuming you are using the Admin UI here. If so, you need first to select a Resource (among the ones available) and then the Type combo will be populated with all the provision rules defined for that Resource. Finally, you will need to provide the external attribute to which the new Virtual Schema's attributes will be linked. More details available at: https://syncope.apache.org/docs/reference-guide.html#virtual HTH Regards. -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Member at The Apache Software Foundation Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail http://home.apache.org/~ilgrosso/
Creating a virtual schema type ->empty type list
Hi, We are currently evaluating Syncopy as a candidate for our future IDM. We have some choices on the table and we are even considering writing our own IDM from scratch, but that is something I would like to avoid for practical reasons...:) I think that would be inventing the wheel again nowadays. Our neighbor Helsinki University is implementing the same solution, so I thought that I will join the community regarding this one. Anyhow, I have a working Syncopy 2.0.2 running on a Windows server 2012 R2 with mysql as the backbone. It is setup and configured via Apache Maven and is running with Tomcat 8.5 as the container. Everything seems to be working. I have managed to create the connector to our AD with the built in/shipped connector. I have also assigned a resource to that connector. Via that resource, we will pull information from our AD as an initial test. The connector reports that it works. One problem though. I have been able to create all schema types but the virtual one. When I'm supposed to create a virtual schema type for attributes that Syncope will not own and set the ad-resource as the de facto resource, the type drop down list for the virtual schema is empty and just states "Choose one". What am I missing here? Some schema definition topic missed somewhere? This is not a panic question, as we are just evaluating, but I figure that I might save some time to ask via the mailing list first. I do have my own abstractions to do for our own maybe to come IDM...:) Regards, Mikael Mikael Ekblom Systemutvecklare/System developer Arcada, IT Jan-Magnus Janssons plats 1, FIN-00560 Helsingfors, Finland TFn: +358 207 699 467 Mobil: +358 207 699 467
