Re: Null password

2018-05-03 Thread Arnold Miller 
Dear Dima,

 

> Which operation are you doing?

for both CREATE and UPDATE operations (scripts) I get null password.

 

> are you creating a push task?

Yes. I created a Push task for the correspondent resource.

 

> did you add the password to the mapping?


Yes. The mapping is 'password' to '__PASSWORD__'

 


Sent: Wednesday, May 02, 2018 at 10:49 AM
From: "Dima Ayash" 
To: user@syncope.apache.org
Subject: Re: Null password



On 05/02/2018 05:39 PM, Arnold Miller wrote:




Dear Dima,

that is exactly what I'm doing but all I get is a null value. I checked the Syncope db and I see a value there, which is encrypted.



Dear Arnold,

Which operation are you doing? are you creating a push task? did you add the password to the mapping?

Best regards,
Dima Ayash



 

Sent: Wednesday, May 02, 2018 at 9:14 AM
From: "Dima Ayash" 
To: user@syncope.apache.org
Subject: Re: Null password



Dear Arnold,

In the case of the password you need just to use the parameter (password) like the parameter (id) for example, which is mentioned in the comment.

Best regards,
Dima Ayash.
 

On 05/01/2018 11:44 PM, Arnold Miller wrote:



Hi,

still having no idea why this happens.

The comment in the original script says "password: password string, clear text", so 'password' should have this value but it comes null to my script.

 

>>


Hi, I'm trying to push a user to an identity store via scripted sql but I 
always get a null password for every user, even if it is not null in Syncope. 
Anyone knows?
I have these variables in Create Script, all of them null:
password
attributes.get("__PASSWORD__")
attributes.get("password")

Arnold

Re: Order by descending/ascending

2018-05-03 Thread Francesco Chicchiriccò 

On 03/05/2018 17:00, PeeDub wrote:

OK, done.

Issue is here: https://issues.apache.org/jira/browse/SYNCOPE-1308


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/

Re: Order by descending/ascending

2018-05-03 Thread PeeDub 
OK, done. 

Issue is here: https://issues.apache.org/jira/browse/SYNCOPE-1308

-
Paul Fullbright
--
Sent from: http://syncope-user.1051894.n5.nabble.com/

Re: volunteering with syncope

2018-05-03 Thread Francesco Chicchiriccò 

On 02/05/2018 19:13, Mike K wrote:

Francesco,
thanks for getting back to me.

I read the contributing tutorial but where can I start should I just 
dive in and start working on this task

https://helpwanted.apache.org/task.html?4878d3f5cef089085e3f6534712485ac0fbabdaa
then submit a bug report if I find anything wrong with the document .


That's fine: consider that you can just fork

https://github.com/apache/syncope

and send a PR for your changes: the documentation is built with 
AsciiDoctor, sources are under


src/main/asciidoc

and you can build it as explained by

http://syncope.apache.org/building.html#Building_documentation

Should you have some AngularJS skills, take a look at

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

Should you have some Eclipse skills, take a look at

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

Regards.

On May 2, 2018, at 2:21 AM, Francesco Chicchiriccò 
> wrote:


On 30/04/2018 21:10, Mike wrote:
I am new to the group and would like to know where can volunteer my 
time to help with the project


Hi Mike,
glad to hear this :-)

Please take a look at

http://syncope.apache.org/contributing

as starting point and then revert: we can discuss some of your ideas 
or pick up something existing.


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: Order by descending/ascending

2018-05-03 Thread Francesco Chicchiriccò 

On 02/05/2018 18:19, PeeDub wrote:

OK, that was the problem. Our Postgres was *TOO* new. I downgraded to 9.6 and
it works.


Ah ok, now I see.


You might check out running on Postgres 10.3.


Sure, I will run the whole test suite against the latest PostgreSQL 10: would 
you mind opening an issue on JIRA about the problem you have found?

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: Provisioning Realms

2018-05-03 Thread Martin van Es 
Hi,

On Thu, May 3, 2018 at 12:43 PM Andrea Patricelli <
andreapatrice...@apache.org> wrote:

> > Realms created in the root realm:
> > CREATE SUCCESS (key/name): 3a3370df-3aa2-4787-b370-df3aa2278786///Foobar
> > CREATE SUCCESS (key/name):
38d90785-ab9c-4fc8-9907-85ab9c2fc8e4///Foobar2
> > CREATE SUCCESS (key/name):
b3c86117-400b-457d-8861-17400bf57d5d///Foobar3
> Please check if realm path is correctly created on Syncope.

The Foobar realm's path is /Foobar, as expected.

> [1] http://blog.tirasa.net/syncope-basics-manage-active-directory.html

I've checked the blog and since it's intended for AD I have to mold it into
LDAP only configuration a bit. Also, my realms come from organizations
instead of organizationalUnit, but I assume that doesn't matter for the
excersice. I have done that to the best of my knowledge, knowing that
mapping organization only wouldn't apply the (!(objectClass=dcObject))
filter, effectively resulting in one too many Realms, but I could live with
that. The original problem however still remains: consecutively pulling in
the Realms results in unique key violoations.

Since I deployed Syncope from debian packages I'm not in a position to
develop, compile and deploy custom pull Actions. Also, I accept the Realms
being inserted in a flat hierarchy, so I don't need any special mapping I
hope?

Best regards,
Martin

Re: Provisioning Realms

2018-05-03 Thread Andrea Patricelli 

Hi Martin,

first of all I suggest to refer to this blog post [1] to have a 
reference on how con configure (also) mapping for realm provisioning.



Il 03/05/2018 12:14, Martin van Es ha scritto:

Hi,

This is related to my earlier question about creating Realms based on
dynamic VO's (organized as o= entities in LDAP).

I'm trying to get FULL RECONCILIATION working, which succeeds for the first
time, but results in unique "u_realm_name" constraint violations on second
attempt, even though I have set matching rule to ignore. So, it seems
syncope has no way of understand what realms are allready provisioned and
this is intended as a one-time provision action?

Not at all.


The setup uses the __ACCOUNT__ objectclass, because that's the only way I
got the search code to apply my object filter (I don't want objects of
objectClass=dcObject). Mapping to organization only doesn't apply this
filter.

In the mapping, I assign internal 'name' to  external 'o' (Remote Key,
purpose: <-) and use Object link 'o='+name+',dc=scz,dc=vnet'.

I set the resource Account objectClass to organization and LDAP Filter for
Retrieving Accounts to (!(objectClass=dcObject)). I can see this working
correctly when I explore the resource.

First time pull results in these succeful actions:
Realms [created/failures]: 3/0 [updated/failures]: 0/0 [deleted/failures]:
0/0 [no operation/ignored]: 0/0

Realms created in the root realm:
CREATE SUCCESS (key/name): 3a3370df-3aa2-4787-b370-df3aa2278786///Foobar
CREATE SUCCESS (key/name): 38d90785-ab9c-4fc8-9907-85ab9c2fc8e4///Foobar2
CREATE SUCCESS (key/name): b3c86117-400b-457d-8861-17400bf57d5d///Foobar3

Please check if realm path is correctly created on Syncope.


But all succesive attempts result in these exceptions in the
core-connid.log (abbreviated for readability):

org.apache.openjpa.persistence.EntityExistsException: The transaction has
been rolled back.  See the nested exceptions for details on the errors that
occurred.

Caused by: org.apache.openjpa.persistence.EntityExistsException: ERROR:
duplicate key value violates unique constraint "u_realm_name"
   Detail: Key (name, parent_id)=(Foobar,
ea696a4f-e77a-4ef1-be67-8f8093bc8686) already exists. {prepstmnt 220401755
INSERT INTO Realm (id, name, ACCOUNTPOLICY_ID, PARENT_ID,
PASSWORDPOLICY_ID) VALUES (?, ?, ?, ?, ?)} [code=0, state=23505]
While pulling realms you need to correctly manage the realm matching, 
please refer to the blog post to correctly configure realms pull 
(§Advanced: Pull Organizational Units as Syncope Realms).

If I set matching policy to update, this should never result in an INSERT,
so it's clear there is no match and the provisioner tries to "provision".

Best regards,
Martin

HTH,
Andrea

[1] http://blog.tirasa.net/syncope-basics-manage-active-directory.html

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

Provisioning Realms

2018-05-03 Thread Martin van Es 
Hi,

This is related to my earlier question about creating Realms based on
dynamic VO's (organized as o= entities in LDAP).

I'm trying to get FULL RECONCILIATION working, which succeeds for the first
time, but results in unique "u_realm_name" constraint violations on second
attempt, even though I have set matching rule to ignore. So, it seems
syncope has no way of understand what realms are allready provisioned and
this is intended as a one-time provision action?

The setup uses the __ACCOUNT__ objectclass, because that's the only way I
got the search code to apply my object filter (I don't want objects of
objectClass=dcObject). Mapping to organization only doesn't apply this
filter.

In the mapping, I assign internal 'name' to  external 'o' (Remote Key,
purpose: <-) and use Object link 'o='+name+',dc=scz,dc=vnet'.

I set the resource Account objectClass to organization and LDAP Filter for
Retrieving Accounts to (!(objectClass=dcObject)). I can see this working
correctly when I explore the resource.

First time pull results in these succeful actions:
Realms [created/failures]: 3/0 [updated/failures]: 0/0 [deleted/failures]:
0/0 [no operation/ignored]: 0/0

Realms created in the root realm:
CREATE SUCCESS (key/name): 3a3370df-3aa2-4787-b370-df3aa2278786///Foobar
CREATE SUCCESS (key/name): 38d90785-ab9c-4fc8-9907-85ab9c2fc8e4///Foobar2
CREATE SUCCESS (key/name): b3c86117-400b-457d-8861-17400bf57d5d///Foobar3

But all succesive attempts result in these exceptions in the
core-connid.log (abbreviated for readability):

org.apache.openjpa.persistence.EntityExistsException: The transaction has
been rolled back.  See the nested exceptions for details on the errors that
occurred.

Caused by: org.apache.openjpa.persistence.EntityExistsException: ERROR:
duplicate key value violates unique constraint "u_realm_name"
  Detail: Key (name, parent_id)=(Foobar,
ea696a4f-e77a-4ef1-be67-8f8093bc8686) already exists. {prepstmnt 220401755
INSERT INTO Realm (id, name, ACCOUNTPOLICY_ID, PARENT_ID,
PASSWORDPOLICY_ID) VALUES (?, ?, ?, ?, ?)} [code=0, state=23505]

If I set matching policy to update, this should never result in an INSERT,
so it's clear there is no match and the provisioner tries to "provision".

Best regards,
Martin
-- 
If 'but' was any useful, it would be a logic operator