Re: Storing Custom User variables and Unique Email constraint

2017-05-08 Thread Francesco Chicchiriccò

On 06/05/2017 00:23, Ravindra Singareddy wrote:


Hi All,

I need to store User Custom variables like firstName, MiddleName, and 
Last Name and using following code:



SyncopeClientFactoryBean clientFactory = new SyncopeClientFactoryBean().
   setAddress("http://localhost:8080/syncope/rest;).
   setDomain("Master").
 setContentType(SyncopeClientFactoryBean.ContentType.XML).
   setUseCompression(true);
SyncopeClient client = clientFactory.create("admin", "password");
UserService userService = client.getService(UserService.class);

UserTO userTo = new UserTO();
  userTo.setUsername(username);
userTo.setPassword(password);
userTo.setCreationDate(new Date());
userTo.setCreator("admin");
userTo.setRealm("/");
userTo.getPlainAttrs().add(new 
AttrTO.Builder().schema("email").value(email).build());
userTo.getPlainAttrs().add(new 
AttrTO.Builder().schema("firstName").value(firstName).build());
userTo.getPlainAttrs().add(new 
AttrTO.Builder().schema("middleName").value(middleName).build());
userTo.getPlainAttrs().add(new 
AttrTO.Builder().schema("lastName").value(lastName).build());

Response userResponse = userService.create(userTo,true);
System.out.println(userResponse.getStatus());

After Successful creation of user,  authenticated using email, with 
following code:


 client = clientFactory.
   setDomain("Master").create(email, password);
Pair, UserTO> self = client.self();
 Object auth = self.getKey();
 UserTO selfUserTO = (UserTO)self.getValue();
System.out.println(selfUserTO);

First Question: selfUserTO is not retrieving firstName, middleName, 
and LastName from Plain Attributes.  What are changes needed to be 
done for storing these plain attributes values?


You need to create the related schemas (if you haven't done that yet) 
and then to assign such schemas to the AnyTypeClass for users.


More information:

https://cwiki.apache.org/confluence/display/SYNCOPE/Apache+Syncope+2.0+Primer
https://syncope.apache.org/docs/reference-guide.html#type-management

Second Question: I am able to save email address and also able to 
retrieve (authenticate) using the email address. If I have created two 
users with the same email address, the system is not able to log in 
using this email address. Because the email address is not unique 
across all users.  How to make email address unique across all users.


You need to change the email schema definition and flag uniqueConstraint 
to true; you can do that either via Admin Console or REST.


Please be aware that, if there are users with the 'email' attribute set, 
such update is not possible: you'll need either to create another schema 
or to remove all the existing email values.


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: Scripted SQL resource

2017-05-08 Thread Francesco Chicchiriccò

On 08/05/2017 09:37, Mikael Ekblom wrote:


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.




Glad that you solved! :-)
Regards.


*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: true* Method: 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…J

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: Scripted SQL resource

2017-05-08 Thread Mikael Ekblom
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