RE: Wrong rest url

[Mikael Ekblom]

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: AW: AW: AW: Configuration of LDAP Identity Store

[Andrea Patricelli]

Hi Martin,


Il 25/07/2017 14:12, Böhmer, Martin ha scritto:


Hi Andrea,

Your proposed solutions are greatly appreciated. Here are my comments:

1.I created a JIRA account to file an improvement request. 
Unfortunately, I seem to lack the right to create an improvement for 
the “LDAP bundle” component. The only components I can create issues 
for are COMMONS, REST & OFFICE365. Am I doing something wrong?



No. Sorry I wasn't aware of it. I've opened [1] for you ;)


2.I not sure, if I understood you correctly. Are you saying, there is 
no chance LDAPMembershipPropagationAction will work out of the box? Or 
that you aren’t you sure if it will work and it would be worth setting 
this up and try it out? If it’s the second case, I would try it you.


I'm quite sure that the propagation action will not work. I experienced 
the same issue little time ago. You should "adapt" it to work out of the 
box, in order to do this you can try without any modification and see 
what is its behavior in order to modify it.


Regards,

Martin


Best regards,
Andrea

[1] https://connid.atlassian.net/browse/LDAP-25


*Von:*Andrea Patricelli [mailto:andreapatrice...@apache.org]
*Ge**sendet:*Montag, 24. Juli 2017 11:33
*An:* user@syncope.apache.org
*Betreff:* Re: AW: AW: Configuration of LDAP Identity Store

Hi Martin,

I perfectly understand your situation.

Please see my responses inline.

Il 22/07/2017 00:53, Böhmer, Martin ha scritto:

Yes, I have set a group mapping. It’s kinda simple:

Type



/User/

Object Class



/__GROUP__/

Mapping
name



/Int: name
ext: cn
Remote key: yes/

Object Link



/‘cn=’ + name + ‘,ou=groups,dc=example,dc=com’/



//



I had a look at the working example you provided. Using “cn” as
the uidAttribute and in the DN for both users and groups worked
fine in my test installation. But, this is only going to work in
case I can influence the way the DNs are structured, so I am able
to harmonise user and group DNs. True for my test environment, but
it is not going to work with our production LDAP.

On the production LDAP server, user DNs are structured “uid=…” and
group DNs “cn=…”. As a result, the “cn” attribute for users is not
a unique identifier, as two different persons can have the same
“cn” in our environment (they will get different uids and email
addresses, etc). There is no way I can change/harmonise the
structure of the DNs (for various reasons).

Setting the uidAttriute to “cn” proved not work with our
production LDAP server - even though the Object Links of the
mappings reflect the differences of the DNs (see above and below).
I do not understand why the uidAttribute of the connector config
influences the remote key generation as the remote key could be
generated only by just evaluating the different ObjectLink JEXL
expressions…

You are right, uidAttribute is only used to retrieve the entity from 
the LDAP server, i.e. the connector will search entities by 
uidAttribute (cn, uid, etc.). For this reason you see the user 
correctly propagated to LDAP, but not correctly linked on Syncope.


So, any ideas on how to get the sync work with the different DNs?

I see two solutions:
1. Implement an improvement on ConnID LDAP connector in order to 
manage two (or more) different uidAttributes (at least one for USER 
and another for GROUP), as done for Active Directory connector. You 
could open an issue (improvement) at [1].
2. Define two different resources, one for USER and the other for 
GROUP, and set uidAttribute as *Override* while configuring the 
connector. With this solution you'll be able to define for each 
resource your specific uidAttribute.
Solution 2 unfortunately has a drawback: 
LDAPMembershipPropagationAction could not work anymore and probably 
needs to be reviewed in order to work with entities related to two 
different resources.


HTH,
Andrea

[1] 
https://connid.atlassian.net/projects/BASE/issues/BASE-56?filter=allopenissues


Regards,

Martin

*Von:*Andrea Patricelli [mailto:andrea.patrice...@tirasa.net]
*Gesendet:* Freitag, 21. Juli 2017 15:35
*An:* user@syncope.apache.org 
*Betreff:* Re: AW: Configuration of LDAP Identity Store

Have you set a mapping for GROUP? Could you share it?
Pay attention to the object link for groups. It should be
something like this: 'cn=' + name + ',ou=groups,dc=sample,dc=com'
If it is correct (as I thisnk) try to use as uidAttribute an
attribute that both USER and GROUP have, and is mapped to any of
Syncope attributes. cn for example.
You have a working example at [1] (Apache DS, resource-ldap).

Best regards,
Andrea

[1] http://syncope-vm.apache.org:9080/syncope-console

Il 21/07/2017 13:15, Böhmer, Martin ha scritto:

Hi Andrea,

Thank you for the 

AW: AW: AW: Configuration of LDAP Identity Store

[Böhmer , Martin]

Hi Andrea,

Your proposed solutions are greatly appreciated. Here are my comments:


1.   I created a JIRA account to file an improvement request. 
Unfortunately, I seem to lack the right to create an improvement for the "LDAP 
bundle" component. The only components I can create issues for are COMMONS, 
REST & OFFICE365. Am I doing something wrong?

2.   I not sure, if I understood you correctly. Are you saying, there is no 
chance LDAPMembershipPropagationAction will work out of the box? Or that you 
aren't you sure if it will work and it would be worth setting this up and try 
it out? If it's the second case, I would try it you.

Regards,

Martin

Von: Andrea Patricelli [mailto:andreapatrice...@apache.org]
Gesendet: Montag, 24. Juli 2017 11:33
An: user@syncope.apache.org
Betreff: Re: AW: AW: Configuration of LDAP Identity Store


Hi Martin,

I perfectly understand your situation.

Please see my responses inline.

Il 22/07/2017 00:53, Böhmer, Martin ha scritto:
Yes, I have set a group mapping. It's kinda simple:
Type

User

Object Class

__GROUP__

Mapping
name

Int: name
ext: cn
Remote key: yes

Object Link

'cn=' + name + ',ou=groups,dc=example,dc=com'





I had a look at the working example you provided. Using "cn" as the 
uidAttribute and in the DN for both users and groups worked fine in my test 
installation. But, this is only going to work in case I can influence the way 
the DNs are structured, so I am able to harmonise user and group DNs. True for 
my test environment, but it is not going to work with our production LDAP.

On the production LDAP server, user DNs are structured "uid=..." and group DNs 
"cn=...". As a result, the "cn" attribute for users is not a unique identifier, 
as two different persons can have the same "cn" in our environment (they will 
get different uids and email addresses, etc). There is no way I can 
change/harmonise the structure of the DNs (for various reasons).

Setting the uidAttriute to "cn" proved not work with our production LDAP server 
- even though the Object Links of the mappings reflect the differences of the 
DNs (see above and below). I do not understand why the uidAttribute of the 
connector config influences the remote key generation as the remote key could 
be generated only by just evaluating the different ObjectLink JEXL 
expressions...
You are right, uidAttribute is only used to retrieve the entity from the LDAP 
server, i.e. the connector will search entities by uidAttribute (cn, uid, 
etc.). For this reason you see the user correctly propagated to LDAP, but not 
correctly linked on Syncope.


So, any ideas on how to get the sync work with the different DNs?
I see two solutions:
1. Implement an improvement on ConnID LDAP connector in order to manage two (or 
more) different uidAttributes (at least one for USER and another for GROUP), as 
done for Active Directory connector. You could open an issue (improvement) at 
[1].
2. Define two different resources, one for USER and the other for GROUP, and 
set uidAttribute as Override while configuring the connector. With this 
solution you'll be able to define for each resource your specific uidAttribute.
Solution 2 unfortunately has a drawback: LDAPMembershipPropagationAction could 
not work anymore and probably needs to be reviewed in order to work with 
entities related to two different resources.

HTH,
Andrea

[1] 
https://connid.atlassian.net/projects/BASE/issues/BASE-56?filter=allopenissues


Regards,

Martin

Von: Andrea Patricelli [mailto:andrea.patrice...@tirasa.net]
Gesendet: Freitag, 21. Juli 2017 15:35
An: user@syncope.apache.org
Betreff: Re: AW: Configuration of LDAP Identity Store

Have you set a mapping for GROUP? Could you share it?
Pay attention to the object link for groups. It should be something like this: 
'cn=' + name + ',ou=groups,dc=sample,dc=com'
If it is correct (as I thisnk) try to use as uidAttribute an attribute that 
both USER and GROUP have, and is mapped to any of Syncope attributes. cn for 
example.
You have a working example at [1] (Apache DS, resource-ldap).

Best regards,
Andrea

[1] http://syncope-vm.apache.org:9080/syncope-console
Il 21/07/2017 13:15, Böhmer, Martin ha scritto:
Hi Andrea,

Thank you for the quick reply!

I changed the uidAttribute as you suggested and sync works for users. However, 
now I have the very same problem with groups whose remote IDs happen to be 
empty.

So, when I change the uidAttribute to "uid", will the same connector also work 
for groups? Or do I need to create a second connector for synchronizing groups?

I am asking, because groups have the attribute "cn" in their dn instead of 
"uid" (see below).

Regards,

Martin

Von: Andrea Patricelli [mailto:andrea.patrice...@tirasa.net]
Gesendet: Freitag, 21. Juli 2017 12:29
An: user@syncope.apache.org
Betreff: Re: Configuration of LDAP Identity Store


Hi Martin,

try to change, in connector configuration, the uidAttribute