unity-idm-discuss — Unity discussion and support

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

Re: [Unity-idm-discuss] disabledCipherSuites Parameter

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

Hi,

W dniu 05.08.2015 o 08:10, Sander Apweiler pisze:
> Hi Krzysztof,
>
> my problem is solved. Thank you very much. Maybe there could be a short
> notice in the documentation.

Right, I'll add it.

Best,
Krzysztof

Re: [Unity-idm-discuss] disabledCipherSuites Parameter

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

Hi Krzysztof,

my problem is solved. Thank you very much. Maybe there could be a short
notice in the documentation.

Best regards,
Sander

On Di, 2015-08-04 at 18:37 +0200, Krzysztof Benedyczak wrote:
> Hi again,
>
> W dniu 31.07.2015 o 14:07, Sander Apweiler pisze:
> > Hi all,
> >
> > i Want to Disable some SSL Ciphers in unity and set the following
> > parameter in unityServer.conf:
> >
> > unityServer.core.httpServer.disabledCipherSuites=ECDHE-RSA-RC4-SHA
> > RC4-MD5 RC4-SHA
> >
> > After restart the server still uses ECDHE-RSA-RC4-SHA cipher. Are there
> > some additional steps to do than restart?
>
> Ahh, I didn't read your config line carefully enough. You have used
> Openssl names of ciphers. You have to use Java cipher names. You can
> find them here:
>
> http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SUNProvider
> (search for Cipher Suites)
>
> So you need something like TLS_ECDHE_RSA_WITH_RC4_128_SHA or
> TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
>
> 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
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------

Re: [Unity-idm-discuss] disabledCipherSuites Parameter

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

Hi again,

W dniu 31.07.2015 o 14:07, Sander Apweiler pisze:
> Hi all,
>
> i Want to Disable some SSL Ciphers in unity and set the following
> parameter in unityServer.conf:
>
> unityServer.core.httpServer.disabledCipherSuites=ECDHE-RSA-RC4-SHA
> RC4-MD5 RC4-SHA
>
> After restart the server still uses ECDHE-RSA-RC4-SHA cipher. Are there
> some additional steps to do than restart?

Ahh, I didn't read your config line carefully enough. You have used 
Openssl names of ciphers. You have to use Java cipher names. You can 
find them here:

http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SUNProvider
(search for Cipher Suites)

So you need something like TLS_ECDHE_RSA_WITH_RC4_128_SHA or 
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA

Best,
Krzysztof

Re: [Unity-idm-discuss] disabledCipherSuites Parameter

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

Hi Sander,

W dniu 31.07.2015 15:07, Sander Apweiler pisze:
> Hi all,
>
> i Want to Disable some SSL Ciphers in unity and set the following
> parameter in unityServer.conf:
>
> unityServer.core.httpServer.disabledCipherSuites=ECDHE-RSA-RC4-SHA
> RC4-MD5 RC4-SHA
>
> After restart the server still uses ECDHE-RSA-RC4-SHA cipher. Are there
> some additional steps to do than restart?


Well, this shouldn't be the case. In general those settings are passed 
directly to an HTTPS server (Jetty) and that's all that Unity does with 
them. I'll check it up, however this is strange as this feature is 
covered by unit test.

Best,
Krzysztof

[Unity-idm-discuss] disabledCipherSuites Parameter

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

Hi all,

i Want to Disable some SSL Ciphers in unity and set the following
parameter in unityServer.conf:

unityServer.core.httpServer.disabledCipherSuites=ECDHE-RSA-RC4-SHA
RC4-MD5 RC4-SHA

After restart the server still uses ECDHE-RSA-RC4-SHA cipher. Are there
some additional steps to do than restart?

Best regards,
Sander



------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
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] Authentication fails

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

W dniu 30.06.2015 o 16:52, Gerben Venekamp pisze:
> Thanks Krzysztof! I am getting a lot further now. I see the SAML
> attributes in the loggin now. What seems to be failing is mapping from
> the identy in the SAML assertion to an identity Uniy understands. If I
> understand correctly, I could take
> urn:mace:dir:attribute-def:eduPersonPrincipalName:
> [be...@ha... <mailto:be...@ha...>] and
> map that to a user within Unity?

Yes of course. You need to properly setup your input translation profile 
(AdminUI -> Server management -> Translation Profiles)

In the profile you have to map what you get from your IdP to Unity 
representation in the way you want. The only mandatory step is to map 
something to Unity identity (of any type you wish).

Relevant docs:
http://unity-idm.eu/documentation/unity-1.6.0/manual.html#_remote_authentication

http://unity-idm.eu/documentation/unity-1.6.0/manual.html#translation

You may find translation profile wizard useful - you can perform a 
"test" authN and then use what Unity get from the IdP as template to 
assemble your profile.

Best,
Krzysztof

Re: [Unity-idm-discuss] Problems creating a Rest Client

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

Hi,

W dniu 15.06.2015 o 16:39, Terefang Verigorn pisze:
> hi!
>
> i am currently trying to implement a rest client in java using
> 'retrofit' and dtos.
>
> the problem that i am having is that that objects returned by a GET
> to "/entity/{entityId}/attribute" are not structurally equivalent to the
> object used in a PUT.
>
> eg. in the first case we have a list of strings (possible base64
> encoded), and in the second case there is a list of json objects.
>
> is this a mistake ?

I don't think there is a mistake. The object used to the put command 
should be similar (same in the syntax sense) as returned in GET. However 
in case of GET you will receive more information (whether the attribute 
is directly defined and what is the syntax).

Maybe you refer to attribute values? Values are always in a json array 
and what is the syntax of the element of the array is governed by the 
attribute syntax. The JPEG image value is encoded in a totally different 
way than say integer number. If you are asking about something different 
can you please paste the example?

Best,
Krzysztof

[Unity-idm-discuss] Problems creating a Rest Client

[Terefang V. <ter...@gm...>]

hi!

i am currently trying to implement a rest client in java using 'retrofit'
and dtos.

the problem that i am having is that that objects returned by a GET
to "/entity/{entityId}/attribute" are not structurally equivalent to the
object used in a PUT.

eg. in the first case we have a list of strings (possible base64 encoded),
and in the second case there is a list of json objects.

is this a mistake ?

cheers,
--
Terefang

Re: [Unity-idm-discuss] Authentication fails

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

Dear Gerben,

W dniu 15.06.2015 o 09:42, Gerben Venekamp pisze:
> Dear Krzysztof,
>
> Yes, I have configured Unity with the metadata from the IdP. This IdP
> acts as a proxy to the federation. Looking at the metadata from
> http://metadata.aai.switch.ch/metadata.aaitest.xml, I think I am seeing
> the metadata of all members of the federation. I don’t want to know the
> individual members of the federation. Instead, I would like rely on the
> proxy, which knows about the federation. This part seems to work for me,
> as I am presented with a WAYF page.

This is fine, however the syntax is the problem. Unity can load 
federation's metadata only, it do not automatically convert a given 
federation member's metadata into ad-hoc one member only federation. But 
OK, in such case you can of course use manual configuration.


> Using one of the presented members,
> I am able to authenticate. However, upon returning to Unity and
> completing the authN, I get a failure in Unity. It complains that the
> Authentication failed, due to either invalid user name, credential or
> external authentication failed. I have included a number of screen shots
> to show what is happening. What is successful and what is not.
>
> Start of the authentication process...
> This the WAYF page.
> This is where I provide my credentials
> Returning to Unity, gives me the following screen.
> My feeling is that everything works as expected, with the exception of
> the last steps in Unity and I do not know what I have done in my
> configurations. I am using Unities DIY certificate for the moment and
> have checked with the IdP if self signed certificates are allowed. This
> should not be a problemen and there are IdP which in fact use self
> signed certificates.

Unity's certificate is not a problem: if it was a problem then Surfonext 
would protest.

What I can see from the error message is that you have configured this 
wrong:

unity.saml.requester.remoteIdp.1.samlId=https://engine.surfconext.nl/authentication/idp/single-sign-on

Saml identifier of the surfonext instance you use is:
https://engine.surfconext.nl/authentication/idp/metadata


Besides of fixing this issue also make sure that you have correctly 
installed the certificate of the service. The pem file starting with 
"MIID3zCCAseg..." should be on Unity box, and defined in pki.properties 
with the key SURFconext:

unity.pki.certificates.SURFconext.certificateFile=...


In case of further problems please provide the DEBUG log.

HTH,
Krzysztof

Re: [Unity-idm-discuss] Authentication fails

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

Hi,

W dniu 12.06.2015 o 12:18, Gerben Venekamp pisze:
> Running the latest version of Unity: 1.6.0
>
> I tried to configure it with the metadatasource, however this gives me
> the following warning:
>
> 2015-06-12 11:44:30,376 [pool-1-thread-1] DEBUG
> unity.server.saml.MetaDownloadManager  - Downloading metadata from
> https://engine.surfconext.nl/authentication/idp/metadata to
> /var/lib/unity-idm/workspace/downloadedMetadata/75681424e34ca7710fa9a3bf0b398bd2_part
> 2015-06-12 11:44:31,454 [pool-1-thread-1] DEBUG
> unity.server.saml.MetaDownloadManager  - Downloaded metadata from
> https://engine.surfconext.nl/authentication/idp/metadata to final file
> /var/lib/unity-idm/workspace/downloadedMetadata/75681424e34ca7710fa9a3bf0b398bd2
> 2015-06-12 11:44:31,495 [pool-1-thread-1] WARN
> unity.server.saml.RemoteMetaManager  - Metadata from
> https://engine.surfconext.nl/authentication/idp/metadata was downloaded,
> but can not be parsed
> org.apache.xmlbeans.XmlException: Element
> EntityDescriptor@urn:oasis:names:tc:SAML:2.0:metadata is not a valid
> EntitiesDescriptor@urn:oasis:names:tc:SAML:2.0:metadata document or a
> valid substitution.


You have configured IdP metadata instead of the federation metadata 
(which includes this Idp's metadata). The federation metadata root 
element is EntitiesDescriptor.

If you don't have it (test installation etc) you can manually create 
one: take the IdP metadata and wrap it in Entities descriptor element, 
save and use file:// url.

E.g. see this one:

http://metadata.aai.switch.ch/metadata.aaitest.xml

(You can ignore extensions etc.)

>
> I have encountered it in version 1.5.0 as well and decided to use manual
> configuration instead:
>
> 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/single-sign-on
> 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-ormat:transient
> unity.saml.requester.remoteIdp.1.translationProfile=SURFconext

OK, do you have the full log already? Especially what is around the 
aforementioned error message.

Best,
Krzysztof

[Unity-idm-discuss] Fwd: Release 1.6.0 available

[Terefang V. <ter...@gm...>]

hi!


On Fri, Jun 12, 2015 at 11:04 AM, Krzysztof Benedyczak <go...@ic...>
wrote:
>
> OK, so rest API is here a way to go. Note that 'loading on startup' is bit
> more confusing, as it work as expected during the first start and can mess
> your setup after subsequent restart (e.g. if you manually fixed one
> attribute type and then after restart you get the old definition).
>
> So yes, this is pretty easy to be added to the REST API, can go into
> 1.7.0. What is another low hanging fruit is a possibility to import
> attribute type definitions directly from LDAP schema. The converter is
> implemented in Unity but not exposed. I can enable it if you find this
> useful.
>

the rest api is definitely the way to go, as the attribute definition may
be more complex than what simple ldif is capable of.

i agree, if one could do a simple http-post with a ldif-schema in the body,
a lot of people would be satisfied with it.

the question is rather what subset or extension of ldif do you want to
support, without being a pain for average users.

for example "ENUMS": about 50% of attribute definitions i use (that dont
map directly to ldap) are enums.

in your case you might at least support X-ENUM and X-PATTERN, for
compatiblity
( see
http://docs.forgerock.org/en/opendj/2.6.0/admin-guide/index/chap-schema.html#attr-syntax-schema-definition-extensions
)


cheers,

--
Terefang

Re: [Unity-idm-discuss] Authentication fails

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

Running the latest version of Unity: 1.6.0

I tried to configure it with the metadatasource, however this gives me the following warning:

2015-06-12 11:44:30,376 [pool-1-thread-1] DEBUG unity.server.saml.MetaDownloadManager  - Downloading metadata from https://engine.surfconext.nl/authentication/idp/metadata to /var/lib/unity-idm/workspace/downloadedMetadata/75681424e34ca7710fa9a3bf0b398bd2_part
2015-06-12 11:44:31,454 [pool-1-thread-1] DEBUG unity.server.saml.MetaDownloadManager  - Downloaded metadata from https://engine.surfconext.nl/authentication/idp/metadata to final file /var/lib/unity-idm/workspace/downloadedMetadata/75681424e34ca7710fa9a3bf0b398bd2
2015-06-12 11:44:31,495 [pool-1-thread-1] WARN  unity.server.saml.RemoteMetaManager  - Metadata from https://engine.surfconext.nl/authentication/idp/metadata was downloaded, but can not be parsed
org.apache.xmlbeans.XmlException: Element EntityDescriptor@urn:oasis:names:tc:SAML:2.0:metadata is not a valid EntitiesDescriptor@urn:oasis:names:tc:SAML:2.0:metadata document or a valid substitution.

I have encountered it in version 1.5.0 as well and decided to use manual configuration instead:

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/single-sign-on
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-ormat:transient
unity.saml.requester.remoteIdp.1.translationProfile=SURFconext

Regads,
Gerben

> On 11 Jun 2015, at 16:22, Shiraz Memon <a....@fz...> wrote:
> 
> Hi Gerben,
> 
> I would like to know which Unity version are you running and what is the SURFConext's remote IdP configuration inside the remoteSamlAuth.properties?
> 
> A tip: use the metadataSource style of configuration:
> 
> unity.saml.requester.metadataSource.surfconext.url=https://url_to_your_idp_metadata_file <https://url_to_your_idp_metadata_file/>
> unity.saml.requester.metadataSource.surfconext.perMetadataTranslationProfile=some_InputAttributeTranslationProfile (optional)
> unity.saml.requester.metadataSource.surfconext.perMetadataRegistrationForm=some_RegistrationForm (optional)
> 
> set the following property in log4j.properties file to see more detailed saml specific exchanges
> log4j.logger.unity.server.saml=DEBUG
> 
> Furthermore, you may enable signature verification by,
> 
> unity.saml.requester.metadataSource.surfconext.signaturVerification=require
> unity.saml.requester.metadataSource.surfconext.signatureVerificationCertificate=SURFCONEXT_IDP_CERTIFICATE (should be defined in the conf/pki.properties file)
> 
> Finally refresh the authenticators and endpoints.
> 
> Cheers,
> Shiraz
> 
> 
> On Thu, Jun 11, 2015 at 11:50 AM, Gerben Venekamp <ger...@su... <mailto:ger...@su...>> wrote:
> Dear all,
> 
> I am having difficulties in setting up Unity for federated access. What I have done thus far is make use of an external SAML IdP, which provides federated authentication. The external IdP is SURFconext. My configuration seems to be working in so far that I am able to see and use the WAYF page. This is still within a test environment. After having selected an IdP from the WAYF page, I am asked for credentials. This also works as expected. When I return however, Unity logs the below lines:
> 
> 2015-06-11 11:20:00,838 [qtp406265225-43] DEBUG unity.server.saml.RedirectRequestHandler  - Starting SAML HTTP Redirect binding exchange with IdPhttps://engine.surfconext.nl/authentication/idp/single-sign-on <https://engine.surfconext.nl/authentication/idp/single-sign-on>
> 2015-06-11 11:20:16,973 [qtp406265225-44] DEBUG unity.server.saml.SamlHttpServlet  - Got SAML response using the HTTP POST binding
> 2015-06-11 11:20:17,233 [qtp406265225-44] WARN  unity.server.saml.SAMLRetrievalUI  - SAML response verification or processing failed
> pl.edu.icm.unity.server.authn.AuthenticationException: The SAML response is either invalid or is issued by an untrusted identity provider.
> 
> Looking at the HTTP response, I can received the following:
> POST https://unity.sara.cloudlet.sara.nl:2443/unitygw/spSAMLResponseConsumer <https://unity.sara.cloudlet.sara.nl:2443/unitygw/spSAMLResponseConsumer> HTTP/1.1
> Host: unity.sara.cloudlet.sara.nl <http://unity.sara.cloudlet.sara.nl/>:2443
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Firefox/38.0
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Language: en-US,en;q=0.5
> Accept-Encoding: gzip, deflate
> Referer: https://engine.surfconext.nl/authentication/sp/consume-assertion <https://engine.surfconext.nl/authentication/sp/consume-assertion>
> Cookie: lastAuthenticationUsed=samlWeb_remoteIdp.1.
> Content-Type: application/x-www-form-urlencoded
> Content-Length: 7755
> 
> HTTP/?.? 302 Found
> X-Frame-Options: DENY
> Location: https://unity.sara.cloudlet.sara.nl:2443/home/home/ <https://unity.sara.cloudlet.sara.nl:2443/home/home/>
> Content-Length: 0
> What I am trying to do is to have a user login in a federated manner as a test to see if my configuration works. The SAML response lists the requested attributes, so that seems fine.
> 
> What I can make of the debug info is that the certificate is not trusted. I am not sure which certificate that is. The federated IdP  should work with self signed certificates, this I checked with the service itself. It puzzels me why I also see the DENY for the redirect. Is that based on the fact of the untrusted certificate? This seems likely and what do I need to do to get a trusted certificate, i.e. what part of the configuration did I do not get right?
> 
> Many thanks,
> Gerben Venekamp
> 
> ------------------------------------------------------------------------------
> 
> _______________________________________________
> 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>
> 
> 
> 
> 
> -- 
> Ahmed Shiraz Memon
> Federated Systems and Data
> Jülich Supercomputing Centre (JSC)
> 
> Phone: +49 2461 61 6899
> Fax:     +49 2461 61 6656
> 
> 
> ------------------------------------------------------------------------------------------------
> ------------------------------------------------------------------------------------------------
> 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] Release 1.6.0 available

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

Hi,

W dniu 10.06.2015 o 12:12, Terefang Verigorn pisze:
>     Well, why at server startup? What is the use case?
>
>     I'd prefer to add such feature to the REST API if you prefer to do
>     it in some automated way. Or there can be some bulk import/export
>     from UI (actually this is implemented, but only as a part of the
>     import/export of the whole database). I need to know your
>     requirements in more details first to suggest something concrete.
>
>
> ok
>
> * use case #1: "Provisioning on Server Installation"
> by installing a new instance,
> i would like to create a number (~50) of attributes,
> mostly coming from ldap-schema.
>
> * use case #2: "Provisioning on new Application Rollout"
> having developed a new application that needs additional attributes,
> or need to update an existing attribute enum,
> or need to update an existing attribute regex-check
>
>
> having attribute-definition in the rest api would actually be sufficient,
> since one can package a script as part of the install or upgrade procedure.
>
> would this make it into 1.7.0 ?

OK, so rest API is here a way to go. Note that 'loading on startup' is 
bit more confusing, as it work as expected during the first start and 
can mess your setup after subsequent restart (e.g. if you manually fixed 
one attribute type and then after restart you get the old definition).

So yes, this is pretty easy to be added to the REST API, can go into 
1.7.0. What is another low hanging fruit is a possibility to import 
attribute type definitions directly from LDAP schema. The converter is 
implemented in Unity but not exposed. I can enable it if you find this 
useful.

Best,
Krzysztof