unity-idm-discuss — Unity discussion and support

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

Re: [Unity-idm-discuss] Authentication fails

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

Dear Gerben,

W dniu 11.06.2015 o 11:50, Gerben Venekamp pisze:
> 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 IdP
> 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:
>
> *POSThttps://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
> *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/
> *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?

To debug in more details the Shiraz suggestion:
log4j.logger.unity.server.saml=DEBUG

is what you need to do. Or even set it to TRACE, than you will see 
everything that goes on the wire. Furthermore with the lines of the 
stack trace, that should be in your log file just below what you have 
pasted it should be possible to give some hints even now.

In general there are tons of possibilities why verification fails, most 
probably it is configuration problem. So your *remote saml authenticator 
settings* are relevant. Maybe this is that the certificate of the 
surfconext service that is not trusted as you guess.

Regarding the 'DENY' in
*X-Frame-Options*: DENY
it is security measure to prevent clickjacking attacks, nothing related.

Best,
Krzysztof

Re: [Unity-idm-discuss] Authentication fails

[Shiraz M. <a....@fz...>]

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




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

[Unity-idm-discuss] Authentication fails

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

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 IdP 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 HTTP/1.1
Host: 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
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/
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

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

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

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

cheers,
--
Terefang

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

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

Hi Terefang,

W dniu 09.06.2015 o 12:45, Terefang Verigorn pisze:
> hi!
>
> many thanks for the new release!
>
> in particular the rest api will allow me to drop my custom plugins.

You're welcome! it great that you can reduce code to maintain.

>
> i am still looking for a way to load new attribute-definitions
> (based on existing syntax) into the server.
>
> i would like to do this via config-file (during server startup).
>
> any idea ?

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.

Best,
Krzysztof

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

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

hi!

many thanks for the new release!

in particular the rest api will allow me to drop my custom plugins.

i am still looking for a way to load new attribute-definitions
(based on existing syntax) into the server.

i would like to do this via config-file (during server startup).

any idea ?

PS: keep up with the good work

C,
--
Terefang

[Unity-idm-discuss] Release 1.6.0 available

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

Dear All,

The release 1.6.0 of Unity server is ready for download.

The highlights of this release are:

* Unity appearance and its control was generally improved.
   - New modern theme
   - The login screen was fully reorganized to be more user friendly and 
flexible: you can use authentication tiles, and choose tile contents 
presentation mode
   - Custom style modifications are possible now, also per endpoint
   - Web page loading time was significantly improved

* Merging of accounts (entities) is possible now, in a number of 
variants: admin and user driven.

* Besides self-modifiable attributes it is possible now to use 
self-modifiable identities.

* Enhanced REST API with write operations

Please note that this is the 1.6.x releases are the last supporting Java 
7. From the 1.7.0 version Unity will require Java 8 to be started.

Please make sure to read the detailed update instruction, which can be 
found in documentation before upgrading.


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

[Unity-idm-discuss] Java 8 migration

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

Dear All,

Early notice about our future plans: Unity will be moved to Java 8 from 
the release 1.7.0.

Note that 1.7.0 is not the next release, which will be 1.6.0. 1.7.0 can 
be expected no sooner then at the end of May.

Current support for Java 8 in distributions is improving: already now 
Centos 6 and 7 contains Java 8 as well as Fedora. Debian stable does not 
but Java 8 can be installed from additional repositories (besides the 
Oracle packages which are always available, however less convenient for 
administrators).

Best regards,
Krzysztof

Re: [Unity-idm-discuss] Unity as UNICORE/X attribute source

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

Hi Björn,

W dniu 06.02.2015 o 14:04, Björn Hagemeier pisze:
> Hi all,
>
> last summer (July 10), Krzysztof reported that pull mode should be
> possible acc. to the UNICORE/X documentation. However, I found some
> missing bits and pieces to really make it work (for me). As far as I can
> see from my changes in the unityServer.conf, the most important
> configuration is to allow certificate based authentication on the
> SAMLUnicoreSoapIdP endpoint. In order to achieve that, I needed a certWS
> authenticator, which seemed to have been missing so far.
>
> Here's a diff of the relevant portions in unityServer.conf:
>
> ==================================================
> +unityServer.core.authenticators.5.authenticatorName=certWS
> +unityServer.core.authenticators.5.authenticatorType=certificate with
> cxf-certificate
> +unityServer.core.authenticators.5.localCredential=Certificate credential
> +unityServer.core.authenticators.5.retrievalConfigurationFile=conf/authenticators/empty.json
> [...]	
>   unityServer.core.endpoints.4.endpointType=SAMLUnicoreSoapIdP
> -unityServer.core.endpoints.4.endpointConfigurationFile=conf/endpoints/saml-webidp.properties
> +unityServer.core.endpoints.4.endpointConfigurationFile=conf/endpoints/saml-unicoreidp.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
> +unityServer.core.endpoints.4.endpointAuthenticators=certWS;pwdWS
>   ==================================================
>
> This configuration is working well for me. However, I am wondering
> whether this can be correct or is even required. After all I guessed the
> setup of the additional authenticator and the changes to the endpoint.
> Ok, looking back into the documentation (Sect. 3.5) I do see the
> relevant snippet, though the example is not quite right (s/pwdWS/certWS/).
>
> The endpoint for the AssertionQueryService needs to be guessed. Maybe it
> is obvious for knowledgeable people, but it does not appear in either
> the Unity or the UNICORE/X manual.

Regarding this part:
1) the typo in section 3.5 of documentation was fixed, thanks for 
spotting it

2) regarding the *default* configuration of the UNICORE SOAP Idp 
endpoint, what you have in the distro is suited for use with UCC and 
cert-less login. Your changes to enable the pull mode from the server 
are correct: UNICORE server can identify itself only with a certificate 
so certificate authenticator is required.
That's said I don't see any problem with changing the defaults here, 
i.e. to add a 'certWS' authenticator to the default configuration. Will 
be in the next release.

3) Endpoint address - right, it is not trivial to find it. You can see 
the base path of the address in the Server Management->Endpoints tab, 
after expanding the appropriate endpoint. You have to open this base 
address: CXF reports all the services, including the detailed addresses.


And yes, you are right - there is no UNICORE+Unity howto, and it is 
needed. The address should be provided there.


> Which are the settings for the services consuming attributes? Which
> roles do they need? Can they have local roles within a VO/Group? Acc. to
> the developer Wiki there are (were?) issues with this setup as well as
> the setup for group administration[1]. Do services need to be members of
> the groups which they query? How do I best set their xlogin (nobody?) if
> I want to use an attribute class requiring xlogin and role to be set?

The settings should be the same as in case of using any other attribute 
source. In most cases the role should be 'server' and xlogin unset or 
nobody - however this depends on a site.

You can set the local roles in a group - this is a generic Unity 
feature, always available.

The issues mentioned in the developer's oriented wiki are related to a 
limited authorization of Unity management. I.e. there are some 
limitations if you want to have a person who can administer only a 
specific group of Unity groups tree.

No, services (and all other clients) need not to be members of groups 
they query. They need to have read permission there. So they need (at 
least) read permission on the group or on any of parent group.

There are many possible approaches to set xlogin and role for services 
and users, this really depends on your scenario. Couple of hints:
- If you have different mappings per site then create group for each site.
- Use group attribute statements to assign default or common values.
- Also to copy attributes to have uniform view.

Consider a quite sophisticated example:

/siteA/servers <- all servers with attribute statement assigning fixed 
role=server and xlogin=nobody
/siteA/users <- all users, attribute statement assigning role=user and 
xlogin set individually
/siteA <- used in endpoint's configuration. Has attribute statements 
that copy the role and xlogin attribute from servers and users subgroups.

> BTW, speaking of attribute classes. It is quite some hassle to modify an
> attribute class for any given group. I think I do understand why this is
> so, but from the point of view of usability it seems like a nightmare
> (please don't take this as an offense). I did find a workaround
> (temporary group), but maybe that should not be required. This is more
> of a general issue than a UNICORE specific one. I haven't had a look at
> the latest release 1.5.0 yet, maybe some of that has gone by now.

Hard to comment - what is the problem? If you want to set mandatory 
attributes requirement it is a hassle by definition (mandatory is 
mandatory, dot). Rule of thumb: use mandatory attributes *only* for 
attributes that you have to define manually, and the attribute really 
must be always set. Attributes which have sensible defaults, especially 
those assigned by attribute statements, should be included in the 
'allowed' enumeration of the class.


> Once these issues have been sorted out, I'd like to provide a concise
> howto on the relevant steps to get UNICORE/X going with UNITY as the
> attribute source. IMO, this is a very valuable use case, but the
> description not fully there, at least not in one piece.
Yes, this is a very much needed effort. Of course I'll contribute.

Cheers,
Krzysztof

[Unity-idm-discuss] Unity as UNICORE/X attribute source

[Björn H. <b.h...@fz...>]

Hi all,

last summer (July 10), Krzysztof reported that pull mode should be
possible acc. to the UNICORE/X documentation. However, I found some
missing bits and pieces to really make it work (for me). As far as I can
see from my changes in the unityServer.conf, the most important
configuration is to allow certificate based authentication on the
SAMLUnicoreSoapIdP endpoint. In order to achieve that, I needed a certWS
authenticator, which seemed to have been missing so far.

Here's a diff of the relevant portions in unityServer.conf:

==================================================
+unityServer.core.authenticators.5.authenticatorName=certWS
+unityServer.core.authenticators.5.authenticatorType=certificate with
cxf-certificate
+unityServer.core.authenticators.5.localCredential=Certificate credential
+unityServer.core.authenticators.5.retrievalConfigurationFile=conf/authenticators/empty.json
[...]	
 unityServer.core.endpoints.4.endpointType=SAMLUnicoreSoapIdP
-unityServer.core.endpoints.4.endpointConfigurationFile=conf/endpoints/saml-webidp.properties
+unityServer.core.endpoints.4.endpointConfigurationFile=conf/endpoints/saml-unicoreidp.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
+unityServer.core.endpoints.4.endpointAuthenticators=certWS;pwdWS
 ==================================================

This configuration is working well for me. However, I am wondering
whether this can be correct or is even required. After all I guessed the
setup of the additional authenticator and the changes to the endpoint.
Ok, looking back into the documentation (Sect. 3.5) I do see the
relevant snippet, though the example is not quite right (s/pwdWS/certWS/).

The endpoint for the AssertionQueryService needs to be guessed. Maybe it
is obvious for knowledgeable people, but it does not appear in either
the Unity or the UNICORE/X manual.

Which are the settings for the services consuming attributes? Which
roles do they need? Can they have local roles within a VO/Group? Acc. to
the developer Wiki there are (were?) issues with this setup as well as
the setup for group administration[1]. Do services need to be members of
the groups which they query? How do I best set their xlogin (nobody?) if
I want to use an attribute class requiring xlogin and role to be set?

BTW, speaking of attribute classes. It is quite some hassle to modify an
attribute class for any given group. I think I do understand why this is
so, but from the point of view of usability it seems like a nightmare
(please don't take this as an offense). I did find a workaround
(temporary group), but maybe that should not be required. This is more
of a general issue than a UNICORE specific one. I haven't had a look at
the latest release 1.5.0 yet, maybe some of that has gone by now.

Once these issues have been sorted out, I'd like to provide a concise
howto on the relevant steps to get UNICORE/X going with UNITY as the
attribute source. IMO, this is a very valuable use case, but the
description not fully there, at least not in one piece.


Cheers,
Björn

[1] https://www.assembla.com/spaces/unity-public/wiki/Authorization


-- 
Dipl.-Inform. Björn Hagemeier
Federated Systems and Data
Juelich Supercomputing Centre
Institute for Advanced Simulation

Phone: +49 2461 61 1584
Fax  : +49 2461 61 6656
Email: b.h...@fz...
Skype: bhagemeier
WWW  : http://www.fz-juelich.de/jsc

JSC is the coordinator of the
John von Neumann Institute for Computing
and member of the
Gauss Centre for Supercomputing

-------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------
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.5.0 available

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

Dear All,

The release 1.5.0  was published on 30.01.2015

Unity 1.5.0 is the first release in which not only a core functionality 
but also the user experience started to be addressed.

The release highlights are:

* Translation profiles creation - the most complicated step of remote 
IdP configuration - is now supported by two new facilities: 
Debugger and Profile creation wizard.

* Frequently requested e-mail confirmations are now available. Unity 
provides a complete and generic support for this service.

* Internalization of Unity was improved. From now on all end-user 
visible names (e.g. credential or attribute names) are now independent 
from internal identifiers and can be provided in all languages which are 
enabled in the server. What is more a complete (with exception of Admin 
UI) Polish translation is now available.

* HomeUI (user's profile) starts to be really functional: users can see 
configured attributes, edit some of them, remove their account and more.

Big thanks to all our contributors, in particular Roman Krysiński for 
his magnificent work on translation profile debugging and wizard and 
Piotr Piernik for his work on e-mail confirmations.

The full list of changes (there are many more!) & updated documentation 
are available as always at http://www.unity-idm.eu/site/downloads

Best regards,
Krzysztof

Re: [Unity-idm-discuss] custom servlet endpoint authentication

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

Hi,

W dniu 27.01.2015 o 20:26, Terefang Verigorn pisze:
> hi!
>
> ok my auth enumberation is working and already authenticating :-)))

Great to hear this!


> i have another suggestion to make:
>
> for installing plugins/additions via package-management it might be
> beneficial to change the way the start-script calculates the classpath.
>
> instead of
>
> CP=.$(find "$LIB" -name '*.jar' -exec printf ":{}" \;)
>
> use
>
> CP=.$(find "$LIB" -type d -exec printf ":{}/*" \;)
>
> this will shorten the commandline considerably and still include jar
> files from subdirs.

This won't influence command line in anyway as classpath is exported as 
an env var.

However, the requirement to have loading of jars from extensions 
directories sounds reasonable. I'll have to perform some tests and 
likely it will be included in 1.6.0.

Thanks!
Krzysztof