unity-idm-discuss — Unity discussion and support

Re: [Unity-idm-discuss] Using UNICORE with Unity

[Alvaro A. <alv...@tu...>]

Hi Bern,

when I add the authenticator to the endpoint like this:

...
unityServer.core.authenticators.6.authenticatorName=ldapZIH
unityServer.core.authenticators.6.authenticatorType=ldap with web-password
unityServer.core.authenticators.6.verificatorConfigurationFile=conf/authenticators/ldap-zih.properties
unityServer.core.authenticators.6.retrievalConfigurationFile=conf/authenticators/passwordRetrieval.json
...
unityServer.core.endpoints.4.endpointType=SAMLUnicoreSoapIdP
unityServer.core.endpoints.4.endpointConfigurationFile=conf/endpoints/saml-webidp.properties
unityServer.core.endpoints.4.contextPath=/unicore-soapidp
unityServer.core.endpoints.4.endpointRealm=defaultRealm
unityServer.core.endpoints.4.endpointName=UNITY UNICORE SOAP SAML service
unityServer.core.endpoints.4.endpointAuthenticators=pwdWS;certWS;ldapZIH


I get the following error:

------------------
2015-11-30 10:12:07,007 [main] FATAL unity.server.EngineInitialization  
- Can't load endpoints which are configured
java.lang.NullPointerException
         at 
pl.edu.icm.unity.engine.EndpointManagementImpl.deployInt(EndpointManagementImpl.java:128)
         at 
pl.edu.icm.unity.engine.EndpointManagementImpl.deploy(EndpointManagementImpl.java:97)
         at 
pl.edu.icm.unity.engine.internal.EngineInitialization.loadEndpointsFromConfiguration(EngineInitialization.java:768)
         at 
pl.edu.icm.unity.engine.internal.EngineInitialization.initializeEndpoints(EngineInitialization.java:721)
         at 
pl.edu.icm.unity.engine.internal.EngineInitialization.initializeDatabaseContents(EngineInitialization.java:351)
         at 
pl.edu.icm.unity.engine.internal.EngineInitialization.start(EngineInitialization.java:209)
         at 
org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:173)
         at 
org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:51)
         at 
org.springframework.context.support.DefaultLifecycleProcessor$LifecycleGroup.start(DefaultLifecycleProcessor.java:346)
         at 
org.springframework.context.support.DefaultLifecycleProcessor.startBeans(DefaultLifecycleProcessor.java:149)
         at 
org.springframework.context.support.DefaultLifecycleProcessor.onRefresh(DefaultLifecycleProcessor.java:112)
         at 
org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:770)
         at 
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:483)
         at 
pl.edu.icm.unity.server.UnityApplication.run(UnityApplication.java:49)
         at 
pl.edu.icm.unity.server.UnityApplication.main(UnityApplication.java:58)
2015-11-30 10:12:07,010 [main] WARN 
org.springframework.context.support.ClassPathXmlApplicationContext - 
Exception encountered during context initialization - cancelling refresh 
attempt
org.springframework.context.ApplicationContextException: Failed to start 
bean 'pl.edu.icm.unity.engine.internal.EngineInitialization#0'; nested 
exception is pl.edu.icm.unity.exceptions.InternalException: Can't load 
endpoints which are configured
         at 
org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:176)
         at 
org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:51)
         at 
org.springframework.context.support.DefaultLifecycleProcessor$LifecycleGroup.start(DefaultLifecycleProcessor.java:346)
         at 
org.springframework.context.support.DefaultLifecycleProcessor.startBeans(DefaultLifecycleProcessor.java:149)
         at 
org.springframework.context.support.DefaultLifecycleProcessor.onRefresh(DefaultLifecycleProcessor.java:112)
         at 
org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:770)
         at 
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:483)
         at 
pl.edu.icm.unity.server.UnityApplication.run(UnityApplication.java:49)
         at 
pl.edu.icm.unity.server.UnityApplication.main(UnityApplication.java:58)
Caused by: pl.edu.icm.unity.exceptions.InternalException: Can't load 
endpoints which are configured
         at 
pl.edu.icm.unity.engine.internal.EngineInitialization.initializeEndpoints(EngineInitialization.java:725)
         at 
pl.edu.icm.unity.engine.internal.EngineInitialization.initializeDatabaseContents(EngineInitialization.java:351)
         at 
pl.edu.icm.unity.engine.internal.EngineInitialization.start(EngineInitialization.java:209)
         at 
org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:173)
         ... 8 more
Caused by: java.lang.NullPointerException
         at 
pl.edu.icm.unity.engine.EndpointManagementImpl.deployInt(EndpointManagementImpl.java:128)
         at 
pl.edu.icm.unity.engine.EndpointManagementImpl.deploy(EndpointManagementImpl.java:97)
         at 
pl.edu.icm.unity.engine.internal.EngineInitialization.loadEndpointsFromConfiguration(EngineInitialization.java:768)
         at 
pl.edu.icm.unity.engine.internal.EngineInitialization.initializeEndpoints(EngineInitialization.java:721)
         ... 11 more
-----------------


do you know what's wrong with that?

I can add the authenticator to the SAMLUnicoreWebIdP endpoint without 
problem, but that's not what I need.

Thanks
Alvaro






On 11/30/2015 09:59 AM, Bernd Schuller wrote:
> hi,
>
> did you add the LDAP authenticator to the unicore-soapidp endpoint?
>
> If yes, try debug logging on Unity and/or UNICORE/X to find out more...
>
>
> Best regards,
> Bernd.
>
> On 30.11.2015 09:51, Alvaro Aguilera wrote:
>> Hello,
>>
>> I'm trying to get Unicore use Unity to validate users using our LDAP
>> server and could use a little help from someone with experience on this.
>> Until now I have set up a Unity server and created a simple
>> authenticator for LDAP (code below), as well as the corresponding
>> translation profile (also below).
>> The dry test of the TP seems to be working well
>>
>> I also added the certificate of the Unity server to Unicore's assertion
>> issuers and granted access to the LDAP users in the XUUDB.
>>
>> However, I'm still unable to login to Unicore using the rich client with
>> the Unity option.
>>
>> Any hints about what I'm missing or doing wrong?
>>
>> Thanks!
>> Alvaro
>>
>>
>> ------------------------------
>>
>>
>> *wsrflite.xml (both for registry & unicore/x)
>>
>> *<property name="container.security.trustedAssertionIssuers.type"
>> value="directory" />
>> <property
>> name="container.security.trustedAssertionIssuers.directoryLocations.1"
>> value="/home/somepath.../unity..pem" />
>>
>>
>> *uas.conf*
>>
>> container.security.rest.authentication.order=FILE UNITY
>> container.security.rest.authentication.UNITY.class=eu.unicore.services.rest.security.UnitySAMLAuthenticator
>> container.security.rest.authentication.UNITY.address=https://unity.zih.tu-dresden.de:2443/unicore-soapidp/saml2unicoreidp-soap/AuthenticationService
>> container.security.rest.authentication.UNITY.validate=true
>>
>>
>> *Authenticator*
> [...]
>>
>> *Translation Profile (LDAP-Test)*
>>
> [...]
>
>
> ------------------------------------------------------------------------------------------------
> ------------------------------------------------------------------------------------------------
> Forschungszentrum Juelich GmbH
> 52425 Juelich
> Sitz der Gesellschaft: Juelich
> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
> Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
> Prof. Dr. Sebastian M. Schmidt
> ------------------------------------------------------------------------------------------------
> ------------------------------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------------
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
> _______________________________________________
> Unity-idm-discuss mailing list
> Uni...@li...
> https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss


-- 
Dipl.-Inf. Alvaro Aguilera
Wissenschaftlicher Mitarbeiter

Technische Universität Dresden
Zentrum für Informationsdienste und Hochleistungsrechnen
Verteiltes und Datenintensives Rechnen

Büro:   Falkenbrunnen, Raum 256
         Chemnitzer Straße 46b
         01187 Dresden
Tel:    +49 (351) 463 33491
Email:  alv...@tu...
Web:    http://www.tu-dresden.de/zih

OTR-Fingerprint:
9CD3BC97 ACFB7430 D084BA9D 4BEB1775 4B0BA9F1

Re: [Unity-idm-discuss] Using UNICORE with Unity

[Bernd S. <b.s...@fz...>]

hi,

did you add the LDAP authenticator to the unicore-soapidp endpoint?

If yes, try debug logging on Unity and/or UNICORE/X to find out more...


Best regards,
Bernd.

On 30.11.2015 09:51, Alvaro Aguilera wrote:
> Hello,
>
> I'm trying to get Unicore use Unity to validate users using our LDAP
> server and could use a little help from someone with experience on this.
> Until now I have set up a Unity server and created a simple
> authenticator for LDAP (code below), as well as the corresponding
> translation profile (also below).
> The dry test of the TP seems to be working well
>
> I also added the certificate of the Unity server to Unicore's assertion
> issuers and granted access to the LDAP users in the XUUDB.
>
> However, I'm still unable to login to Unicore using the rich client with
> the Unity option.
>
> Any hints about what I'm missing or doing wrong?
>
> Thanks!
> Alvaro
>
>
> ------------------------------
>
>
> *wsrflite.xml (both for registry & unicore/x)
>
> *<property name="container.security.trustedAssertionIssuers.type"
> value="directory" />
> <property
> name="container.security.trustedAssertionIssuers.directoryLocations.1"
> value="/home/somepath.../unity..pem" />
>
>
> *uas.conf*
>
> container.security.rest.authentication.order=FILE UNITY
> container.security.rest.authentication.UNITY.class=eu.unicore.services.rest.security.UnitySAMLAuthenticator
> container.security.rest.authentication.UNITY.address=https://unity.zih.tu-dresden.de:2443/unicore-soapidp/saml2unicoreidp-soap/AuthenticationService
> container.security.rest.authentication.UNITY.validate=true
>
>
> *Authenticator*
[...]
>
>
> *Translation Profile (LDAP-Test)*
>
[...]


------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------

[Unity-idm-discuss] Using UNICORE with Unity

[Alvaro A. <alv...@tu...>]

Hello,

I'm trying to get Unicore use Unity to validate users using our LDAP 
server and could use a little help from someone with experience on this.
Until now I have set up a Unity server and created a simple 
authenticator for LDAP (code below), as well as the corresponding 
translation profile (also below).
The dry test of the TP seems to be working well

I also added the certificate of the Unity server to Unicore's assertion 
issuers and granted access to the LDAP users in the XUUDB.

However, I'm still unable to login to Unicore using the rich client with 
the Unity option.

Any hints about what I'm missing or doing wrong?

Thanks!
Alvaro


------------------------------


*wsrflite.xml (both for registry & unicore/x)

*<property name="container.security.trustedAssertionIssuers.type" 
value="directory" />
<property 
name="container.security.trustedAssertionIssuers.directoryLocations.1" 
value="/home/somepath.../unity..pem" />


*uas.conf*

container.security.rest.authentication.order=FILE UNITY
container.security.rest.authentication.UNITY.class=eu.unicore.services.rest.security.UnitySAMLAuthenticator
container.security.rest.authentication.UNITY.address=https://unity.zih.tu-dresden.de:2443/unicore-soapidp/saml2unicoreidp-soap/AuthenticationService
container.security.rest.authentication.UNITY.validate=true


*Authenticator*

ldap.bindAs=system
ldap.systemDN=cn=blahblah,dc=zih,dc=tu-dresden,dc=de
ldap.systemPassword=secret
ldap.servers.1=ldap-server.zih.tu-dresden.de
ldap.ports.1=636
ldap.connectionMode=SSL
ldap.trustAllServerCertificates=true
ldap.userDNTemplate=uid={USERNAME},ou=users,dc=tu-dresden,dc=de
ldap.groupsBaseName=ou=groups,dc=tu-dresden,dc=de
ldap.groups.1.objectClass=posixGroup
ldap.groups.1.memberAttribute=memberUid
ldap.groups.1.nameAttribute=cn
ldap.groups.1.matchByMemberAttribute=cn
ldap.translationProfile=LDAP-Test



*Translation Profile (LDAP-Test)*

1: Condition: true
         Action: mapIdentity
         Action parameters:
         unityIdentityType = x500Name
         expression = id
         credential requirement = Password requirement
         effect = CREATE_OR_MATCH
2: Condition: true
         Action: mapIdentity
         Action parameters:
         unityIdentityType = userName
         expression = attr['uid']
         credential requirement = Password requirement
         effect = CREATE_OR_MATCH
3: Condition: true
         Action: mapAttribute
         Action parameters:
         unityAttribute = cn
         group = /
         expression = attr['cn']
         visibility = full
         effect = CREATE_OR_UPDATE
4: Condition: true
         Action:mapAttribute
         Action parameters:
         unityAttribute = urn:unicore:attrType:xlogin
         group = /
         expression = attr['uid']
         visibility = full
         effect = CREATE_OR_UPDATE
5: Condition: true
         Action: mapAttribute
         Action parameters:
         unityAttribute = email
         group = /
         expression = attr['mail']
         visibility = full
         effect = CREATE_OR_UPDATE




-- 
Dipl.-Inf. Alvaro Aguilera
Wissenschaftlicher Mitarbeiter

Technische Universität Dresden
Zentrum für Informationsdienste und Hochleistungsrechnen
Verteiltes und Datenintensives Rechnen

Büro:   Falkenbrunnen, Raum 256
         Chemnitzer Straße 46b
         01187 Dresden
Tel:    +49 (351) 463 33491
Email:alv...@tu...
Web:http://www.tu-dresden.de/zih

OTR-Fingerprint:
9CD3BC97 ACFB7430 D084BA9D 4BEB1775 4B0BA9F1

[Unity-idm-discuss] Revision 1.7.2 released

[Krzysztof B. <go...@ic...>]

Dear All,


A new revision release 1.7.2 is available, fixing several problems, 
generally minor, however significant in some deployments.


The most important changes include:
-) strict and complete email address validation
-) clearing of IdP SAML/OAuth context when using registration form an 
the endpoint, with custom redirects
-) not duplicating SAML session participants used for SLO


The full list of changes with additional details are available as always
at http://www.unity-idm.eu/site/downloads

Best regards,
Krzysztof

[Unity-idm-discuss] Bugfix 1.7.1 release

[Krzysztof B. <go...@ic...>]

Dear All,

the 1.7.1 release was published, fixing several bugs found in 1.7.0.
The most significant bug was related to PostgreSQL transactions 
handling, which were randomly failing on higher load.

The full list of changes with additional details are available as always 
at http://www.unity-idm.eu/site/downloads

Best regards,
Krzysztof

Re: [Unity-idm-discuss] Unity 1.7.0

[Bernd S. <b.s...@fz...>]

hi Alvaro,

the error means that the code was compiled for Java 1.8
To run it, you need to use Java 1.8 as well.

Best regards,
Bernd.



On 09.11.2015 13:23, Alvaro Aguilera wrote:
> Hello,
>
> I just installed Unity 1.7.0 and get the following error when starting
>
>
> Exception in thread "main" java.lang.UnsupportedClassVersionError:
> pl/edu/icm/unity/server/UnityApplication : Unsupported major.minor
> version 52.0
>          at java.lang.ClassLoader.defineClass1(Native Method)
>          at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
>          at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>          at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
>          at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
>          at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
>          at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
>          at java.security.AccessController.doPrivileged(Native Method)
>          at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
>          at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
>          at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
>          at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
>          at
> sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482)
>
>
> does anyone know where the problem lies?
>
> Thanks
> Alvaro
>
>
>
>
> ------------------------------------------------------------------------------
> Presto, an open source distributed SQL query engine for big data, initially
> developed by Facebook, enables you to easily query your data on Hadoop in a
> more interactive manner. Teradata is also now providing full enterprise
> support for Presto. Download a free open source copy now.
> http://pubads.g.doubleclick.net/gampad/clk?id=250295911&iu=/4140
>
>
>
> _______________________________________________
> Unity-idm-discuss mailing list
> Uni...@li...
> https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss
>


------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------

[Unity-idm-discuss] Unity 1.7.0

[Alvaro A. <alv...@tu...>]

Hello,

I just installed Unity 1.7.0 and get the following error when starting


Exception in thread "main" java.lang.UnsupportedClassVersionError: 
pl/edu/icm/unity/server/UnityApplication : Unsupported major.minor 
version 52.0
         at java.lang.ClassLoader.defineClass1(Native Method)
         at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
         at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
         at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
         at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
         at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
         at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
         at java.security.AccessController.doPrivileged(Native Method)
         at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
         at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
         at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
         at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
         at 
sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482)


does anyone know where the problem lies?

Thanks
Alvaro


-- 
Dipl.-Inf. Alvaro Aguilera
Wissenschaftlicher Mitarbeiter

Technische Universität Dresden
Zentrum für Informationsdienste und Hochleistungsrechnen
Verteiltes und Datenintensives Rechnen

Büro:   Falkenbrunnen, Raum 256
         Chemnitzer Straße 46b
         01187 Dresden
Tel:    +49 (351) 463 33491
Email:  alv...@tu...
Web:    http://www.tu-dresden.de/zih

OTR-Fingerprint:
9CD3BC97 ACFB7430 D084BA9D 4BEB1775 4B0BA9F1

Re: [Unity-idm-discuss] Mail to deleted unity users

[Sander A. <sa....@fz...>]

Hi,

sorry for the long period of silence. I think i have solved this issue.
The user and identifier was deleted but not the entities. I deleted them
now.

Best regards,
Sander

On Di, 2015-09-22 at 12:51 +0200, Krzysztof Benedyczak wrote:
> Hi,
>
> W dniu 16.09.2015 o 14:56, Sander Apweiler pisze:
> > Hi all,
> >
> > i have a problem with the mailing behavior from unity. Unity tries to
> > send an email to a testuser with an not existing email-address. The user
> > is already deleted but unity still tries to send a confirmation mail to
> > this user. How i can stop this?
>
> Are you sure it is Unity? Unity will send (if configured so) a
> confirmation email to check if the email is valid. It is also in the
> case of not existing user: during registration. The confirmation is sent
> exactly once in any case.
>
> Maybe your SMTP is resending an email (originating from Unity) due to
> any of SMTP-justified cases? If you are positive that it is Unity
> submitting repeatedly emails to SMTP server, can you please more
> precisely describe the steps to reproduce?
>
> Best,
> Krzysztof
>




------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------

[Unity-idm-discuss] Release 1.7.0 is available

[Krzysztof B. <go...@ic...>]

Dear All,

The release 1.7.0 of Unity server is ready for download.

Note: since this version Java 8 is required to run Unity.

The 1.7.0 release in the first place fixes numerous bugs that were found 
in 1.6.x releases.

The most important new features are:
  - Support for PostgreSQL database backend.
  - It is possible now to access (public) registration forms with a well 
known URLs. You need a special endpoint for this feature (enabled in 
1.7.0 by default). The public link of a form is visible in its settings 
in AdminUI.
  - It is possible to redirect user browser after registration and after 
confirming an email. This mechanism was partially available before (only 
for registration) but was reworked so redirection has rich information 
passed with parameters about operation state.
  - A new input translation action - remove stale data - is available. 
It allows for removing stale data from Unity, so Unity database can be 
kept in sync with remote IdP.


Big thanks to everybody involved in this release!


The full list of changes with additional details are available as always 
at http://www.unity-idm.eu/site/downloads

Best regards,
Krzysztof

Re: [Unity-idm-discuss] Mail to deleted unity users

[Krzysztof B. <go...@ic...>]

Hi,

W dniu 16.09.2015 o 14:56, Sander Apweiler pisze:
> Hi all,
>
> i have a problem with the mailing behavior from unity. Unity tries to
> send an email to a testuser with an not existing email-address. The user
> is already deleted but unity still tries to send a confirmation mail to
> this user. How i can stop this?

Are you sure it is Unity? Unity will send (if configured so) a 
confirmation email to check if the email is valid. It is also in the 
case of not existing user: during registration. The confirmation is sent 
exactly once in any case.

Maybe your SMTP is resending an email (originating from Unity) due to 
any of SMTP-justified cases? If you are positive that it is Unity 
submitting repeatedly emails to SMTP server, can you please more 
precisely describe the steps to reproduce?

Best,
Krzysztof

[Unity-idm-discuss] Mail to deleted unity users

[Sander A. <sa....@fz...>]

Hi all,

i have a problem with the mailing behavior from unity. Unity tries to
send an email to a testuser with an not existing email-address. The user
is already deleted but unity still tries to send a confirmation mail to
this user. How i can stop this?

Best regards,
Sander Apweiler



------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------

Re: [Unity-idm-discuss] LDAP as backend for Unity

[Krzysztof B. <go...@ic...>]

Dear Gerben,

W dniu 11.09.2015 o 11:45, Gerben Venekamp pisze:
> Dear Krzysztof,
>
> Thanks for the reply. I did not explain myself well enough…
>
> What I failed to make clear was that the services are of a distributed
> nature. In other words, the service is run across multiple sites. In
> this kind of setup, LDAP is already being deployed. When a user has
> access to a distributed service, it must be able to authenticate for
> that service at all the different sites the service is hosted. Sites
> usually have LDAP already running and adding to their existing LDAP
> infrastructure is relatively easy. What happens is that there is a
> master LDAP directory, which gets copied (replicated) to all involved
> sites. This enables that a user is allowed to access a service on any of
> the involved sites. It also ensures that all local sites do not have to
> add a user to their local LDAP. It relieves local sites from doing all
> the same thing and relieves the user in getting access to all sites
> where the service is deployed.
>
> The above described setup requires obviously a registration process.
> Currently users are added to the master LDAP directories in different
> ways, but non of them are federated. The idea is to make this
> registration process federated. In other words we are looking into
> putting Unity on top of the existing LDAP infrastructure in order to
> make the LDAP infrastructure federated. There is also a benefit in it.
> In case Unity is unavailable for authentication, we could fall back to
> the credentials in the LDAP directory and the service keeps running for
> those users. Also, tooling already makes use of LDAP and thus those are
> able benefit from federated authentication.
>
> The setup that I am thinking of is depicted in the attached image. In
> this picture, a users accesses either the service on site A or B. The
> LDAP could be used to authenticate the users (it will have short lived
> credentials), or Unity is used for federated authentication. Unity adds
> or updates the validated user to/in the LDAP directory.
>
>
>
>
> Hopefully I have explained myself better this time. :-) What are your
> thoughts on this?

OK, now I got it (I think). Sorry to say, but this is impossible (in 
general, not as Unity can't do something). Simply put you can't 
provision federated users to a local DB (as LDAP) as you never get 
user's credential during federated login. [and one remark mostly about 
wording: if you want to really "federate" your LDAPs you need an 
additional IdP software (Unity/Shib IdP/...) per each LDAP instance.]

You can have your local users in LDAP and federated users (in their IdPs 
which you can't control). If the federation gateway (as Unity) is down 
you can still use local LDAP if it is up, but not federated logins - 
those can not be magically "cached" locally.
You can in general ask about a local credential during registration of a 
first-time federation user. However this won't be federated access 
anymore and in general makes little sense.

For your setup you can go two ways:
1) setup single Unity to be a federation bridge plus expose LDAP login. 
Setup services to use Unity if available and local LDAP it not (what 
would be a degraded mode). Easy on Unity side, but can be a lot of work 
on (all) services side.
2) setup Unity as above but two instances using shared DB (and same 
configs) plus HA switching e.g. IP in DNS is changed when primary is 
down. Then you can easily configure services to use Unity. But a lot of 
work on Unity & its RDBMS side.

Best,
Krzysztof

Re: [Unity-idm-discuss] LDAP as backend for Unity

[Gerben V. <ger...@su...>]

Dear Krzysztof,

Thanks for the reply. I did not explain myself well enough…

What I failed to make clear was that the services are of a distributed nature. In other words, the service is run across multiple sites. In this kind of setup, LDAP is already being deployed. When a user has access to a distributed service, it must be able to authenticate for that service at all the different sites the service is hosted. Sites usually have LDAP already running and adding to their existing LDAP infrastructure is relatively easy. What happens is that there is a master LDAP directory, which gets copied (replicated) to all involved sites. This enables that a user is allowed to access a service on any of the involved sites. It also ensures that all local sites do not have to add a user to their local LDAP. It relieves local sites from doing all the same thing and relieves the user in getting access to all sites where the service is deployed.

The above described setup requires obviously a registration process. Currently users are added to the master LDAP directories in different ways, but non of them are federated. The idea is to make this registration process federated. In other words we are looking into putting Unity on top of the existing LDAP infrastructure in order to make the LDAP infrastructure federated. There is also a benefit in it. In case Unity is unavailable for authentication, we could fall back to the credentials in the LDAP directory and the service keeps running for those users. Also, tooling already makes use of LDAP and thus those are able benefit from federated authentication.

The setup that I am thinking of is depicted in the attached image. In this picture, a users accesses either the service on site A or B. The LDAP could be used to authenticate the users (it will have short lived credentials), or Unity is used for federated authentication. Unity adds or updates the validated user to/in the LDAP directory.




Hopefully I have explained myself better this time. :-) What are your thoughts on this?

Cheers,
Gerben

> On 08 Sep 2015, at 23:19, Krzysztof Benedyczak <go...@ic...> wrote:
> 
> Dear Gerben,
> 
> W dniu 08.09.2015 o 09:47, Gerben Venekamp pisze:
>> Dear all,
>> 
>> Unity has its own user database and I am wondering if it is possible to
>> use LDAP instead. The second use case described in the Unity
>> documentation (1.1 Use cases) seems to hint at this. However, the
>> remainder of the document does not seem to further detail it. Of course
>> the documentation describes how Unity can be configured to use LDAP for
>> remote authentication. What I would like to know: is Unity able to use
>> LDAP for its user database (instead of using either the H2 or MySql
>> databases)?
>> 
> 
> No, it is not (and won't be) possible. You can only relay on LDAP as an external IdP service.
> 
>> The idea behind this is that Unity can act as a master and replicate the
>> LDAP database to its slaves. This could be valuable when Unity for
>> authentication is temporally not reachable, but services can still
>> validate already known users. It would ensure that people can continue
>> using a service in case Unity in not able to provide authentication.
> 
> Well, I don't understand this idea.
> 
> When you write "Unity can act as a master" do you mean that "LDAP instance used by Unity can act as (LDAP) master"? If so: how this would help you? I don't know what for you use Unity, but I assume it adds some value to your setup. And then if Unity is down you won't be able to operate. If you have a mixed setup and some services use LDAP directly, and some (e.g. web) via Unity with its added features, then you can replicate LDAPs and also set up two Unity instances, each configured to use different LDAP - so you have real HA.
> 
> Or do you have another setup in mind? My interpretations are not really aligned with what you wrote...
> 
> Best regards,
> Krzysztof
> 
> 

Re: [Unity-idm-discuss] LDAP as backend for Unity

[Krzysztof B. <go...@ic...>]

Dear Gerben,

W dniu 08.09.2015 o 09:47, Gerben Venekamp pisze:
> Dear all,
>
> Unity has its own user database and I am wondering if it is possible to
> use LDAP instead. The second use case described in the Unity
> documentation (1.1 Use cases) seems to hint at this. However, the
> remainder of the document does not seem to further detail it. Of course
> the documentation describes how Unity can be configured to use LDAP for
> remote authentication. What I would like to know: is Unity able to use
> LDAP for its user database (instead of using either the H2 or MySql
> databases)?
>

No, it is not (and won't be) possible. You can only relay on LDAP as an 
external IdP service.

> The idea behind this is that Unity can act as a master and replicate the
> LDAP database to its slaves. This could be valuable when Unity for
> authentication is temporally not reachable, but services can still
> validate already known users. It would ensure that people can continue
> using a service in case Unity in not able to provide authentication.

Well, I don't understand this idea.

When you write "Unity can act as a master" do you mean that "LDAP 
instance used by Unity can act as (LDAP) master"? If so: how this would 
help you? I don't know what for you use Unity, but I assume it adds some 
value to your setup. And then if Unity is down you won't be able to 
operate. If you have a mixed setup and some services use LDAP directly, 
and some (e.g. web) via Unity with its added features, then you can 
replicate LDAPs and also set up two Unity instances, each configured to 
use different LDAP - so you have real HA.

Or do you have another setup in mind? My interpretations are not really 
aligned with what you wrote...

Best regards,
Krzysztof

[Unity-idm-discuss] LDAP as backend for Unity

[Gerben V. <ger...@su...>]

Dear all,

Unity has its own user database and I am wondering if it is possible to use LDAP instead. The second use case described in the Unity documentation (1.1 Use cases) seems to hint at this. However, the remainder of the document does not seem to further detail it. Of course the documentation describes how Unity can be configured to use LDAP for remote authentication. What I would like to know: is Unity able to use LDAP for its user database (instead of using either the H2 or MySql databases)?

The idea behind this is that Unity can act as a master and replicate the LDAP database to its slaves. This could be valuable when Unity for authentication is temporally not reachable, but services can still validate already known users. It would ensure that people can continue using a service in case Unity in not able to provide authentication.

Cheers,
Gerben
 
| Data Services | Data & Cloud Services | SURFsara |
| Science Park 140 | 1098 XG Amsterdam | www.surfsara.nl | T +31 (0)20 800 1338 |

Re: [Unity-idm-discuss] Mapping new users to a group

[Gerben V. <ger...@su...>]

Yes, I got it! The expression associated with mapGroup needed to be quoted and that was not immediately clear to me.

Thanks,
Gerben

> On 07 Sep 2015, at 11:57, Krzysztof Benedyczak <go...@ic...> wrote:
> 
> Dear Gerben,
> 
> W dniu 07.09.2015 o 11:27, Gerben Venekamp pisze:
>> Dear all,
>> 
>> I am trying to map a remote user to a group within Unity. I am agble to
>> successfully authenticate remotely. A newly authenticated remote user
>> gets added to /. Also, in the logs I can see the attributes that have
>> been requested. Instead of adding users to the Root group, I want to map
>> users to a new group. This does not seem to work for me and I cannot
>> figure out what I am doing wrong. Unfortunately, the log files do not
>> provide any clues to what is really failing.
> 
> 
> You simply have to use mapGroup action. The mapAttibute action which you use maps an attribute in a group, but it doesn't imply that the user is added to that group. Also note that group membership in Unity is hierarchical: i.e. all users are always in the '/' and you can add them to subgroups (e.g. /A/B member is also member of /A and /).
> 
> HTH
> Krzysztof

Re: [Unity-idm-discuss] Mapping new users to a group

[Krzysztof B. <go...@ic...>]

Dear Gerben,

W dniu 07.09.2015 o 11:27, Gerben Venekamp pisze:
> Dear all,
>
> I am trying to map a remote user to a group within Unity. I am agble to
> successfully authenticate remotely. A newly authenticated remote user
> gets added to /. Also, in the logs I can see the attributes that have
> been requested. Instead of adding users to the Root group, I want to map
> users to a new group. This does not seem to work for me and I cannot
> figure out what I am doing wrong. Unfortunately, the log files do not
> provide any clues to what is really failing.


You simply have to use mapGroup action. The mapAttibute action which you 
use maps an attribute in a group, but it doesn't imply that the user is 
added to that group. Also note that group membership in Unity is 
hierarchical: i.e. all users are always in the '/' and you can add them 
to subgroups (e.g. /A/B member is also member of /A and /).

HTH
Krzysztof

[Unity-idm-discuss] Mapping new users to a group

[Gerben V. <ger...@su...>]

Dear all,

I am trying to map a remote user to a group within Unity. I am agble to successfully authenticate remotely. A newly authenticated remote user gets added to /. Also, in the logs I can see the attributes that have been requested. Instead of adding users to the Root group, I want to map users to a new group. This does not seem to work for me and I cannot figure out what I am doing wrong. Unfortunately, the log files do not provide any clues to what is really failing.

I have the following translation profile:
1: Condition:	
true
Action:	
mapIdentity
Action parameters:	
unityIdentityType = userName
expression = attr['urn:mace:dir:attribute-def:eduPersonPrincipalName']
credential requirement = Password requirement
effect = CREATE_OR_MATCH
2: Condition:	
true
Action:	
mapAttribute
Action parameters:	
unityAttribute = cn
group = /SURFconext
expression = attr['urn:oid:1.3.6.1.4.1.5923.1.1.1.6']
visibility = full
effect = CREATE_OR_UPDATE


When the group in the second condition is set to /, then I can see the user being added to the / group. Of course after restarting the Authenticator. What else do I need to do to add remote users to the /SURFconext group, or any subgroups of /SURFconext for that matter?

Cheers,
Gerben

| Data Services | Data & Cloud Services | SURFsara |
| Science Park 140 | 1098 XG Amsterdam | www.surfsara.nl | T +31 (0)20 800 1338 |

Re: [Unity-idm-discuss] Unable to configure metadata URL

[Gerben V. <ger...@su...>]

Solved my issue. I have been mixing up DNS names a bit and changing the configuration on one VM and checking the effects on another. Indeed for this second VM the metadata was named metedata1. So, in effect I have been putting myself on a wild goose chase so to speak. Now I am getting the response I am expecting.

Cleanup my caches now as not to make this mistake twice…

Thanks,
Gerben


> On 03 Sep 2015, at 15:19, Gerben Venekamp <ger...@su...> wrote:
> 
>> On 03 Sep 2015, at 14:56, Krzysztof Benedyczak <go...@ic... <mailto:go...@ic...>> wrote:
>> 
>> Hi,
>> 
>> W dniu 03.09.2015 o 14:23, Gerben Venekamp pisze:
>>> Recently I have migrated a Unity installation to a different machine. In
>>> doing so, I have changed the configuration slightly. I had to change the
>>> URL of the metadata, because the new machine resolves to a new name. At
>>> the same time I changed the name of the metadata file. In the examples
>>> the metatdata file was always referenced as metadata1. I could not
>>> understand the necessity of the ‘1’ and hence removed it. As it tuned
>>> out, the configured URL leads to a ‘404, Not Found’. No matter what I
>>> name my metadata file in the below configuration, it will always be:
>>> https://unity.sara.cloudlet.sara.nl:2443/unitygw/saml-sp-metadata/metadata*1* <https://unity.sara.cloudlet.sara.nl:2443/unitygw/saml-sp-metadata/metadata*1*>
>>> 
>>> It does not matter if I call it ‘metadata’ or ‘metadataaaaaa’. It always
>>> seems to live at: ‘metadata1’. I am not sure this is a bug, for I cannot
>>> find ‘metadata1’ in the source files (version: 1.6.1). Tried to look
>>> deeper in to the code, but Eclipse (Mars) does not seem to work with
>>> ‘m2e’ and gives me errors. Then again, I am not experienced with Eclipse.
>>> 
>>> My configuration file:
>>> 
>>> unity.saml.requester.requesterEntityId=https://unity.sara.cloudlet.sara.nl:2443/unitygw/saml-sp-metadata/metadata
>>> unity.saml.requester.metadataPath=metadata
>>> unity.saml.requester.requesterCredential=surfsara
>>> unity.saml.requester.acceptedNameFormats.1=urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
>>> unity.saml.requester.acceptedNameFormats.2=urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
>>> unity.saml.requester.acceptedNameFormats.3=urn:oasis:names:tc:SAML:2.0:nameid-format:transient
>>> 
>>> #unity.saml.requester.displayName=Remote SAML authentication (SURFconext)
>>> 
>>> unity.saml.requester.remoteIdp.1.name=SURFconext IdP
>>> unity.saml.requester.remoteIdp.1.address=https://engine.surfconext.nl/authentication/idp/single-sign-on
>>> unity.saml.requester.remoteIdp.1.samlId=https://engine.surfconext.nl/authentication/idp/metadata
>>> unity.saml.requester.remoteIdp.1.certificate=SURFconext
>>> unity.saml.requester.remoteIdp.1.groupMembershipAttribute=urn:oid:1.3.6.1.4.1.5923.1.1.1.1
>>> unity.saml.requester.remoteIdp.1.requestedNameFormat=urn:oasis:names:tc:SAML:2.0:nameid-format:transient
>>> #unity.saml.requester.remoteIdp.1.requestedNameFormat=urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified
>>> unity.saml.requester.remoteIdp.1.translationProfile=SURFconext
>>> 
>>> What must I do to make the metadata appear at the configured URL?
>> 
>> Recap:
>> unity.saml.requester.metadataPath is responsible for the last part of the metadata path, you should set this to change the path.
>> 
>> The unity.saml.requester.requesterEntityId is SAML id which in the end can be any string. However SAML profiles recommend it to be an URL of server's metadata. So you should change it too, but changing it won't influence metadata position.
> 
> I have seen that behaviour indeed. The last part of the URL changes to unity.saml.requester.metadataPath. However, I have kept both the same.
> 
>> 
>> Assuming you set both correctly you have to reload your SAML authenticator (from adminUI servermanagement->authenticators). Only then the new config will be loaded.
> 
> I have done that many times already. Unity tells me that it was successfully reloaded. I have also completely restarted Unity, though. I just did both again. From the samlWeb Authenticator I read the following part of what is configured:
> 
> unity.saml.requester.requesterEntityId=https://unity.sara.cloudlet.sara.nl:2443/unitygw/saml-sp-metadata/metadata <https://unity.sara.cloudlet.sara.nl:2443/unitygw/saml-sp-metadata/metadata>
> unity.saml.requester.metadataPath=metadata
> Using  the following URL in firefox:
> https://unity.sara.cloudlet.sara.nl:2443/unitygw/saml-sp-metadata/metadata <https://unity.sara.cloudlet.sara.nl:2443/unitygw/saml-sp-metadata/metadata>
> 
> results in:
> HTTP Error: 404
> 
> Error reason:
>     No metadata at this location: /metadata
> 
> Cheers,
> Gerben
> ------------------------------------------------------------------------------
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools
> in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140_______________________________________________ <http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140_______________________________________________>
> Unity-idm-discuss mailing list
> Uni...@li... <mailto:Uni...@li...>
> https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss <https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss>

Re: [Unity-idm-discuss] Unable to configure metadata URL

[Gerben V. <ger...@su...>]

> On 03 Sep 2015, at 14:56, Krzysztof Benedyczak <go...@ic...> wrote:
> 
> Hi,
> 
> W dniu 03.09.2015 o 14:23, Gerben Venekamp pisze:
>> Recently I have migrated a Unity installation to a different machine. In
>> doing so, I have changed the configuration slightly. I had to change the
>> URL of the metadata, because the new machine resolves to a new name. At
>> the same time I changed the name of the metadata file. In the examples
>> the metatdata file was always referenced as metadata1. I could not
>> understand the necessity of the ‘1’ and hence removed it. As it tuned
>> out, the configured URL leads to a ‘404, Not Found’. No matter what I
>> name my metadata file in the below configuration, it will always be:
>> https://unity.sara.cloudlet.sara.nl:2443/unitygw/saml-sp-metadata/metadata*1*
>> 
>> It does not matter if I call it ‘metadata’ or ‘metadataaaaaa’. It always
>> seems to live at: ‘metadata1’. I am not sure this is a bug, for I cannot
>> find ‘metadata1’ in the source files (version: 1.6.1). Tried to look
>> deeper in to the code, but Eclipse (Mars) does not seem to work with
>> ‘m2e’ and gives me errors. Then again, I am not experienced with Eclipse.
>> 
>> My configuration file:
>> 
>> unity.saml.requester.requesterEntityId=https://unity.sara.cloudlet.sara.nl:2443/unitygw/saml-sp-metadata/metadata
>> unity.saml.requester.metadataPath=metadata
>> unity.saml.requester.requesterCredential=surfsara
>> unity.saml.requester.acceptedNameFormats.1=urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
>> unity.saml.requester.acceptedNameFormats.2=urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
>> unity.saml.requester.acceptedNameFormats.3=urn:oasis:names:tc:SAML:2.0:nameid-format:transient
>> 
>> #unity.saml.requester.displayName=Remote SAML authentication (SURFconext)
>> 
>> unity.saml.requester.remoteIdp.1.name=SURFconext IdP
>> unity.saml.requester.remoteIdp.1.address=https://engine.surfconext.nl/authentication/idp/single-sign-on
>> unity.saml.requester.remoteIdp.1.samlId=https://engine.surfconext.nl/authentication/idp/metadata
>> unity.saml.requester.remoteIdp.1.certificate=SURFconext
>> unity.saml.requester.remoteIdp.1.groupMembershipAttribute=urn:oid:1.3.6.1.4.1.5923.1.1.1.1
>> unity.saml.requester.remoteIdp.1.requestedNameFormat=urn:oasis:names:tc:SAML:2.0:nameid-format:transient
>> #unity.saml.requester.remoteIdp.1.requestedNameFormat=urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified
>> unity.saml.requester.remoteIdp.1.translationProfile=SURFconext
>> 
>> What must I do to make the metadata appear at the configured URL?
> 
> Recap:
> unity.saml.requester.metadataPath is responsible for the last part of the metadata path, you should set this to change the path.
> 
> The unity.saml.requester.requesterEntityId is SAML id which in the end can be any string. However SAML profiles recommend it to be an URL of server's metadata. So you should change it too, but changing it won't influence metadata position.

I have seen that behaviour indeed. The last part of the URL changes to unity.saml.requester.metadataPath. However, I have kept both the same.

> 
> Assuming you set both correctly you have to reload your SAML authenticator (from adminUI servermanagement->authenticators). Only then the new config will be loaded.

I have done that many times already. Unity tells me that it was successfully reloaded. I have also completely restarted Unity, though. I just did both again. From the samlWeb Authenticator I read the following part of what is configured:

unity.saml.requester.requesterEntityId=https://unity.sara.cloudlet.sara.nl:2443/unitygw/saml-sp-metadata/metadata
unity.saml.requester.metadataPath=metadata
Using  the following URL in firefox:
https://unity.sara.cloudlet.sara.nl:2443/unitygw/saml-sp-metadata/metadata <https://unity.sara.cloudlet.sara.nl:2443/unitygw/saml-sp-metadata/metadata>

results in:
HTTP Error: 404

Error reason:
    No metadata at this location: /metadata

Cheers,
Gerben

Re: [Unity-idm-discuss] Unable to configure metadata URL

[Krzysztof B. <go...@ic...>]

Hi,

W dniu 03.09.2015 o 14:23, Gerben Venekamp pisze:
> Recently I have migrated a Unity installation to a different machine. In
> doing so, I have changed the configuration slightly. I had to change the
> URL of the metadata, because the new machine resolves to a new name. At
> the same time I changed the name of the metadata file. In the examples
> the metatdata file was always referenced as metadata1. I could not
> understand the necessity of the ‘1’ and hence removed it. As it tuned
> out, the configured URL leads to a ‘404, Not Found’. No matter what I
> name my metadata file in the below configuration, it will always be:
> https://unity.sara.cloudlet.sara.nl:2443/unitygw/saml-sp-metadata/metadata*1*
>
> It does not matter if I call it ‘metadata’ or ‘metadataaaaaa’. It always
> seems to live at: ‘metadata1’. I am not sure this is a bug, for I cannot
> find ‘metadata1’ in the source files (version: 1.6.1). Tried to look
> deeper in to the code, but Eclipse (Mars) does not seem to work with
> ‘m2e’ and gives me errors. Then again, I am not experienced with Eclipse.
>
> My configuration file:
>
> unity.saml.requester.requesterEntityId=https://unity.sara.cloudlet.sara.nl:2443/unitygw/saml-sp-metadata/metadata
> unity.saml.requester.metadataPath=metadata
> unity.saml.requester.requesterCredential=surfsara
> unity.saml.requester.acceptedNameFormats.1=urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
> unity.saml.requester.acceptedNameFormats.2=urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
> unity.saml.requester.acceptedNameFormats.3=urn:oasis:names:tc:SAML:2.0:nameid-format:transient
>
> #unity.saml.requester.displayName=Remote SAML authentication (SURFconext)
>
> unity.saml.requester.remoteIdp.1.name=SURFconext IdP
> unity.saml.requester.remoteIdp.1.address=https://engine.surfconext.nl/authentication/idp/single-sign-on
> unity.saml.requester.remoteIdp.1.samlId=https://engine.surfconext.nl/authentication/idp/metadata
> unity.saml.requester.remoteIdp.1.certificate=SURFconext
> unity.saml.requester.remoteIdp.1.groupMembershipAttribute=urn:oid:1.3.6.1.4.1.5923.1.1.1.1
> unity.saml.requester.remoteIdp.1.requestedNameFormat=urn:oasis:names:tc:SAML:2.0:nameid-format:transient
> #unity.saml.requester.remoteIdp.1.requestedNameFormat=urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified
> unity.saml.requester.remoteIdp.1.translationProfile=SURFconext
>
> What must I do to make the metadata appear at the configured URL?

Recap:
unity.saml.requester.metadataPath is responsible for the last part of 
the metadata path, you should set this to change the path.

The unity.saml.requester.requesterEntityId is SAML id which in the end 
can be any string. However SAML profiles recommend it to be an URL of 
server's metadata. So you should change it too, but changing it won't 
influence metadata position.

Assuming you set both correctly you have to reload your SAML 
authenticator (from adminUI servermanagement->authenticators). Only then 
the new config will be loaded.

Best
Krzysztof

[Unity-idm-discuss] Unable to configure metadata URL

[Gerben V. <ger...@su...>]

Recently I have migrated a Unity installation to a different machine. In doing so, I have changed the configuration slightly. I had to change the URL of the metadata, because the new machine resolves to a new name. At the same time I changed the name of the metadata file. In the examples the metatdata file was always referenced as metadata1. I could not understand the necessity of the ‘1’ and hence removed it. As it tuned out, the configured URL leads to a ‘404, Not Found’. No matter what I name my metadata file in the below configuration, it will always be:
  https://unity.sara.cloudlet.sara.nl:2443/unitygw/saml-sp-metadata/metadata1

It does not matter if I call it ‘metadata’ or ‘metadataaaaaa’. It always seems to live at: ‘metadata1’. I am not sure this is a bug, for I cannot find ‘metadata1’ in the source files (version: 1.6.1). Tried to look deeper in to the code, but Eclipse (Mars) does not seem to work with ‘m2e’ and gives me errors. Then again, I am not experienced with Eclipse.

My configuration file:

unity.saml.requester.requesterEntityId=https://unity.sara.cloudlet.sara.nl:2443/unitygw/saml-sp-metadata/metadata
unity.saml.requester.metadataPath=metadata
unity.saml.requester.requesterCredential=surfsara
unity.saml.requester.acceptedNameFormats.1=urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
unity.saml.requester.acceptedNameFormats.2=urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
unity.saml.requester.acceptedNameFormats.3=urn:oasis:names:tc:SAML:2.0:nameid-format:transient

#unity.saml.requester.displayName=Remote SAML authentication (SURFconext)

unity.saml.requester.remoteIdp.1.name=SURFconext IdP
unity.saml.requester.remoteIdp.1.address=https://engine.surfconext.nl/authentication/idp/single-sign-on
unity.saml.requester.remoteIdp.1.samlId=https://engine.surfconext.nl/authentication/idp/metadata
unity.saml.requester.remoteIdp.1.certificate=SURFconext
unity.saml.requester.remoteIdp.1.groupMembershipAttribute=urn:oid:1.3.6.1.4.1.5923.1.1.1.1
unity.saml.requester.remoteIdp.1.requestedNameFormat=urn:oasis:names:tc:SAML:2.0:nameid-format:transient
#unity.saml.requester.remoteIdp.1.requestedNameFormat=urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified
unity.saml.requester.remoteIdp.1.translationProfile=SURFconext

What must I do to make the metadata appear at the configured URL?

Cheers,
Gerben

| Data Services | Data & Cloud Services | SURFsara |
| Science Park 140 | 1098 XG Amsterdam | www.surfsara.nl | T +31 (0)20 800 1338 |

[Unity-idm-discuss] Release 1.6.1 is available

[Krzysztof B. <go...@ic...>]

Dear All,

The release 1.6.1 of Unity server is ready for download.

This release fixes several problems found in the 1.6.0 version, and, in 
the most cases, also older releases. There are also two small new 
features included, which were necessary to make general features of 
1.6.0 fully usable.

Big thanks to everybody involved in this release!

The full list of changes with additional details is available as always 
at http://www.unity-idm.eu/site/downloads

Best regards,
Krzysztof

Re: [Unity-idm-discuss] Unity-idm installation & configuration issues

[Krzysztof B. <go...@ic...>]

Hi Pedro,

W dniu 05.08.2015 o 13:56, Pedro Severino pisze:
> Hi all,
>
> I tried to install unity-idm in one of my machines, the installation was
> really quiet with no issues, I already had java-1.7.0-openjdk on my machine.
>
> Everything runs smotly, but now I can access the web interface, I did
> some changes on the configuration, just the port from 2443 to 443 an
> host from localhost to vo-demo.fccn.pt. When I try to acces
> https://vo-demo.fccn.pt I get the following message:
>
> *HTTP Error: 404*
>
> Error reason:
>
>      Not Found
>
> I can only access this in my network, but do you have any ideia what
> could be the problem? I can’t see any errors on the unity logs.

Everything works correctly, you only miss a path in URL. What paths are 
possible results from your configuration (endpoints) and location in 
endpoints (see manual). For instance try https://vo-demo.fccn.pt/admin/admin

HTH,
Krzysztof

[Unity-idm-discuss] Unity-idm installation & configuration issues

[Pedro S. <ped...@fc...>]

Hi all,

 

I tried to install unity-idm in one of my machines, the installation was
really quiet with no issues, I already had java-1.7.0-openjdk on my machine.

Everything runs smotly, but now I can access the web interface, I did some
changes on the configuration, just the port from 2443 to 443 an host from
localhost to vo-demo.fccn.pt. When I try to acces https://vo-demo.fccn.pt I
get the following message:

HTTP Error: 404

Error reason: 

    Not Found

 

I can only access this in my network, but do you have any ideia what could
be the problem? I can't see any errors on the unity logs.

If you need any other kind of information just ask.

 

Thanks,

 

Pedro Severino