Menu
▾
▴
unity-idm-discuss — Unity discussion and support
You can subscribe to this list here.
| 2014 |
Jan
(3) |
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(2) |
Aug
(2) |
Sep
|
Oct
(3) |
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2015 |
Jan
(20) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
(15) |
Jul
(1) |
Aug
(7) |
Sep
(13) |
Oct
(2) |
Nov
(10) |
Dec
(1) |
| 2016 |
Jan
|
Feb
(2) |
Mar
|
Apr
(2) |
May
(1) |
Jun
|
Jul
(1) |
Aug
(2) |
Sep
(11) |
Oct
(7) |
Nov
(6) |
Dec
(11) |
| 2017 |
Jan
(10) |
Feb
(5) |
Mar
(27) |
Apr
(34) |
May
(25) |
Jun
(14) |
Jul
(7) |
Aug
(17) |
Sep
(11) |
Oct
(6) |
Nov
(14) |
Dec
(10) |
| 2018 |
Jan
(8) |
Feb
(19) |
Mar
(40) |
Apr
(9) |
May
(16) |
Jun
(23) |
Jul
(31) |
Aug
(7) |
Sep
(9) |
Oct
(6) |
Nov
(14) |
Dec
(19) |
| 2019 |
Jan
(4) |
Feb
(6) |
Mar
(1) |
Apr
(2) |
May
(6) |
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(19) |
Dec
(14) |
| 2020 |
Jan
(10) |
Feb
(24) |
Mar
(49) |
Apr
(26) |
May
(12) |
Jun
(4) |
Jul
(13) |
Aug
(32) |
Sep
(13) |
Oct
(10) |
Nov
(4) |
Dec
(16) |
| 2021 |
Jan
(2) |
Feb
(8) |
Mar
(15) |
Apr
(19) |
May
(5) |
Jun
(13) |
Jul
(6) |
Aug
(38) |
Sep
(11) |
Oct
(18) |
Nov
(11) |
Dec
(13) |
| 2022 |
Jan
(10) |
Feb
(21) |
Mar
(28) |
Apr
(3) |
May
(7) |
Jun
(9) |
Jul
(14) |
Aug
(13) |
Sep
(8) |
Oct
(29) |
Nov
(1) |
Dec
(21) |
| 2023 |
Jan
(19) |
Feb
(9) |
Mar
|
Apr
(10) |
May
(7) |
Jun
(10) |
Jul
(14) |
Aug
(17) |
Sep
(1) |
Oct
(9) |
Nov
(5) |
Dec
(14) |
| 2024 |
Jan
(12) |
Feb
(2) |
Mar
(8) |
Apr
(1) |
May
(6) |
Jun
(6) |
Jul
(24) |
Aug
(15) |
Sep
(1) |
Oct
(6) |
Nov
(20) |
Dec
(14) |
| 2025 |
Jan
(12) |
Feb
(2) |
Mar
(10) |
Apr
(11) |
May
(13) |
Jun
(1) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Sander A. <sa....@fz...> - 2019-12-12 12:04:49
|
Dear Krzysztof,
I updated unity from 2.4.2 to 2.8.2. I know that this version is old
too. But we are not ready to update to unity 3.
After the update I have an issue with certificates.
If you select a grid certificate for authentication, it is rejected and
you get a "Secure Connection Failed" error with "SSL peer had some
unspecified issue with the certificate it received." It seems that
unity does not like the Grid cert infrastructure any more. When I use a
global certificate everything went well.
The pki truststore config is the same like in 2.4.2:
unity.pki.truststores.MAIN.type=directory
unity.pki.truststores.MAIN.allowProxy=DENY
unity.pki.truststores.MAIN.directoryLocations.1=/usr/local/unity/certs/*
unity.pki.truststores.MAIN.directoryLocations.2=/etc/grid-security/certificates/*.pem
unity.pki.truststores.MAIN.crlLocations.1=/etc/grid-security/certificates/*.crl
unity.pki.truststores.MAIN.directoryEncoding=PEM
unity.pki.truststores.MAIN.crlUpdateInterval=400
unity.pki.truststores.WEB.type=directory
unity.pki.truststores.WEB.allowProxy=DENY
unity.pki.truststores.WEB.directoryLocations.1=/usr/local/unity/certs/*
unity.pki.truststores.WEB.crlLocations.1=/etc/grid-security/certificates/*.crl
unity.pki.truststores.WEB.directoryEncoding=PEM
unity.pki.truststores.WEB.crlUpdateInterval=400
The authenticator configuration in unityServer.conf was adjusted to
have only one single certificate configuration:
unityServer.core.authenticators.cert.authenticatorName=cert
unityServer.core.authenticators.cert.authenticatorType=certificate
unityServer.core.authenticators.cert.localCredential=Certificate credential
unityServer.core.authenticators.cert.configurationFile=${CONF}/authenticators/certificateRetrieval.properties
Do you have any clue why it is not working anymore? There is no error
in the logs about it.
Cheers,
Sander
--
Federated Systems and Data
Juelich Supercomputing Centre
phone: +49 2461 61 8847
fax: +49 2461 61 6656
email: sa....@fz...
----------------------------------------------------------------------
-----------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Volker Rieke
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
-----------------------------------------------------------------------
-----------------------------------------------------------------------
|
|
From: Krzysztof B. <kb...@un...> - 2019-12-09 12:31:28
|
Dear Subscribers, A new revision release was published. This version is focused on Console stability and includes huge amount of fixes. The most important ones are related to issues around authenticator, service and IdP editors, which were causing some unintentional changes in configuration upon saving. We have developed a specialized testing framework, and hope that we wiped all the bugs in this area. Console got also couple of small styling improvements, some fields were made bigger, OAuth authenticators show return URL that needs to be authorized at upstream OAuth server, etc. This revision includes also one new feature: Unity supports decryption of subject identifiers in SAML logout requests. More details as always at https://www.unity-idm.eu/downloads/ Best regards, Krzysztof |
|
From: Krzysztof B. <kb...@un...> - 2019-12-08 22:04:41
|
W dniu 05.12.2019 o 07:15, Sander Apweiler pisze: >> If so this is perhaps not very complex task, but certainly longer. >> We >> would expose those in the context of input profile of SAML >> authenticator >> (as a new variable, e.g. idpAttrs). So you can either create a >> condition >> on it or just use it as-is for some attribute value. We will also >> need >> to implement IdP side support for it - to be able to automate >> testing. >> >> Does it sound correct to you? > This is almost correct, but in this case the DFN set this attribute in > the metadata not the IdP. Sure - I meant that the attribute is not the user's (SAML assertion subject's) attribute, but should be obtained from IdP settings. |
|
From: Sander A. <sa....@fz...> - 2019-12-05 06:15:50
|
Good morning Krzysztof, On Wed, 2019-12-04 at 21:36 +0100, Krzysztof Benedyczak wrote: > Hi Sander, > > W dniu 02.12.2019 o 08:17, Sander Apweiler pisze: > > Hi Krzysztof, > > > > yes we want to set different level of assurance (within translation > > profile), based on this attribute. This attribute indicates how the > > identity vetting was done at the organisations. > > I've looked into this metadata too (as found here > https://doku.tid.dfn.de/en:metadata) > > So in fact I think you in the end don't want to use 2 metadata > sources, > merged by Unity, but only one: the basic metadata which includes > both > advanced and basic idps. And the only feature missing is to parse > the > SAML metadata extension with IDP attributes, and expose it for the > user > logging through such IdP. Is it all correct? Yes this is correct. > > If so this is perhaps not very complex task, but certainly longer. > We > would expose those in the context of input profile of SAML > authenticator > (as a new variable, e.g. idpAttrs). So you can either create a > condition > on it or just use it as-is for some attribute value. We will also > need > to implement IdP side support for it - to be able to automate > testing. > > Does it sound correct to you? This is almost correct, but in this case the DFN set this attribute in the metadata not the IdP. Cheers, Sander > > Cheers, > Krzysztof -- Federated Systems and Data Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ---------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Volker Rieke Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Krzysztof B. <kb...@un...> - 2019-12-04 20:36:13
|
Hi Sander, W dniu 02.12.2019 o 08:17, Sander Apweiler pisze: > Hi Krzysztof, > > yes we want to set different level of assurance (within translation > profile), based on this attribute. This attribute indicates how the > identity vetting was done at the organisations. I've looked into this metadata too (as found here https://doku.tid.dfn.de/en:metadata) So in fact I think you in the end don't want to use 2 metadata sources, merged by Unity, but only one: the basic metadata which includes both advanced and basic idps. And the only feature missing is to parse the SAML metadata extension with IDP attributes, and expose it for the user logging through such IdP. Is it all correct? If so this is perhaps not very complex task, but certainly longer. We would expose those in the context of input profile of SAML authenticator (as a new variable, e.g. idpAttrs). So you can either create a condition on it or just use it as-is for some attribute value. We will also need to implement IdP side support for it - to be able to automate testing. Does it sound correct to you? Cheers, Krzysztof |
|
From: Sander A. <sa....@fz...> - 2019-12-02 07:17:32
|
Hi Krzysztof, yes we want to set different level of assurance (within translation profile), based on this attribute. This attribute indicates how the identity vetting was done at the organisations. Cheers, Sander On Sat, 2019-11-30 at 19:24 +0100, Krzysztof Benedyczak wrote: > Hi Sander, > > W dniu 29.11.2019 o 10:57, Sander Apweiler pisze: > > Hi Krzysztof, > > I had a deeper look into the metadata file of the basic federation. > > There is an attribute which indicates if an IdP is only basic or > > advanced: > > > > <saml:Attribute Name="http://aai.dfn.de/loa/degree-of-reliance" > > NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> > > <saml:AttributeValue>advanced</saml:AttributeValue> > > > > Do you know a way to use this information later in unity? > > If this is metadata's attribute then Unity offers no feature > allowing > you to process it. So either way we would need an additional feature > to > support your case. Do you want to use this attribute to filter IdPs > from > some metadata documents? > > Cheers > Krzysztof > > -- Federated Systems and Data Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ---------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Volker Rieke Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Krzysztof B. <kb...@un...> - 2019-11-30 18:24:54
|
Hi Sander, W dniu 29.11.2019 o 10:57, Sander Apweiler pisze: > Hi Krzysztof, > I had a deeper look into the metadata file of the basic federation. > There is an attribute which indicates if an IdP is only basic or > advanced: > > <saml:Attribute Name="http://aai.dfn.de/loa/degree-of-reliance" > NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> > <saml:AttributeValue>advanced</saml:AttributeValue> > > Do you know a way to use this information later in unity? If this is metadata's attribute then Unity offers no feature allowing you to process it. So either way we would need an additional feature to support your case. Do you want to use this attribute to filter IdPs from some metadata documents? Cheers Krzysztof |
|
From: Sander A. <sa....@fz...> - 2019-11-29 09:57:31
|
Hi Krzysztof, I had a deeper look into the metadata file of the basic federation. There is an attribute which indicates if an IdP is only basic or advanced: <saml:Attribute Name="http://aai.dfn.de/loa/degree-of-reliance" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml:AttributeValue>advanced</saml:AttributeValue> Do you know a way to use this information later in unity? Cheers, Sander On Mon, 2019-11-18 at 09:06 +0100, Sander Apweiler wrote: > Hi Krzysztof, > > I guessed that it is not possible. Thank you very much for your > investigation to this. > > Best regards, > Sander > > On Mon, 2019-11-18 at 09:03 +0100, Krzysztof Benedyczak wrote: > > Hi Sander, > > > > W dniu 12.11.2019 o 11:51, Sander Apweiler pisze: > > > > If I understood this correctly those are basically two > > > > federations > > > > (two > > > > XMLs with metadata) Basic and Advanced, in Advanced I'll find > > > > all > > > > IdPs > > > > from Basic (same SAML entityIds), right? > > > > > > > > If so how do you envision a choice which one is going to be > > > > used > > > > for > > > > authentication of a user who happens to be in IdP which is > > > > member > > > > of > > > > both? There should be a choice (so user can select) or simply > > > > always > > > > use > > > > the advanced one? > > > > > > If the IdP is part of the advanced class, it should be always > > > used > > > the > > > advanced. There should be no user selection, because user will > > > always > > > end at the same IdP. > > > > I had to verify what the answer is. > > > > So unfortunately this won't work in reliable way: there is no way > > currently in Unity to specify which SAML metadata is overriding > > another > > one. Actually the picture is quite complex as also in Unity you > > can > > define manually (not via metadata) your trusted IdPs. Those guys > > are > > guaranteed to take precedence over all metadata based, but entries > > are > > actually merged. I.e. if metadata brings more details about IdP it > > will > > be added to the manually defined one, but no setting will be > > changed. > > However wrt to the order of metadata provided IdPs there are no > > ways > > to > > control it - the first one will win, but is rather random which > > one > > becomes the first. > > > > Best, > > Krzysztof > > > > > > _______________________________________________ > Unity-idm-discuss mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss -- Federated Systems and Data Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ---------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Volker Rieke Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Krzysztof B. <kb...@un...> - 2019-11-20 23:28:57
|
Dear Subscribers, Unity 3.1.1 was released. This is a bugfix release, fixing three rather serious issues found in releases 3.0.0 and 3.1.0. Update is highly recommended. What is more a small new feature is added allowing for embedding an included translation profile's actions. Detailed changelog is available here <https://www.unity-idm.eu/downloads>, and details of fixed issues are in the release post <https://www.unity-idm.eu/2019/11/20/unity-3-1-1-released/>. Best regards, Krzysztof |
|
From: Krzysztof B. <kb...@un...> - 2019-11-19 22:52:10
|
Hi Sander, For your case, it seems pretty clear. No, no one of the pasted requests is signed. The first one contains encrypted id, so would fail anyway (even if signed) - same case as described in an email to Shiraz. The 2nd one probably would be accepted, if was signed. In case of SLO (more precisely async SLO that you are using) signature is a must: otherwise there is no way to check if the request, coming via redirect, was really issued by someone authorized. Action (logout) is immediate effect, and so we can't relay on other means as in case of SSO protocol (where we can just return a response to a trusted address). HTH, Krzysztof |
|
From: Sander A. <sa....@fz...> - 2019-11-19 14:27:37
|
Hi Krzysztof,
I have a similar issue but unity says the SLO requests are not signed.
The first one is:
<samlp:LogoutRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="ONELOGIN_af44951e9e4082c520a50c150541f0af18ec6389"
Version="2.0"
IssueInstant="2019-11-19T14:16:01Z"
Destination="https://b2access.eudat.eu/saml-idp/SLO-WEB">;
<saml:Issuer>https://b2drop-devel.zam.kfa-juelich.de/index.php/apps/user_saml/saml/metadata</saml:Issuer>;
<saml:EncryptedID><xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" Type="http://www.w3.org/2001/04/xmlenc#Element"><xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/><dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><xenc:EncryptedKey><xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/><xenc:CipherData><xenc:CipherValue>BhnR3pIsntkc1w/ApcUQqaYFera49xOB4W1Ucbv/DbG5ED94QrDYzZsjlUXccsvbE56738cCy5X7nYIDIgAnHs2J/JrQahaxavp9Vhw1m3DBdRCKiG6ydwDyUMlVQr8w/ku3EIe157R77MRnOmu7SIl/wj8Mm5HGxr+Z2zDS99kc7L8s+JCNUKw7es9/ycHtvni4MWhDf6IrhnnxyLutyBw27bwkSaQTQXeYEtqbR4QVtNbObkA86nyqgFLImPvvDgu4ofApM75umMKKEEZ+MafpcGt+qUewRSFHup/El5LO1dHoLCtoPFRxL62hAAftppMx9LZAbbtaQ6TetwzG7Nw80QLaYDDgciOWwLmKMgyr6rVigTn5N18tyFGFcK7wEjL1ZGr8e+Sg6ZwadC/e6tX7IO6/mq6lowRoS5F4p061nC4gOZbg/rQ7vTso3dwbS4pW6Loo8kjDV6hZXZfOXs572NkKS/fDPa4gzTfuydA3u8vU+1txrqWWfYQfQVvUXRZwC0FSjV4tn0pwJjCJ1RoirFy2KcoVNjJVlN9Zh5TExMzoByiM9aQf7BG6SAf+4ICOwvqa4yA09wS/kOmchvfM0qkPtvkux7HB6JRGez2z8qfIqVyTF+ipgEhUePaH5zBMPEwtbQrrH2ylfRx1FCPlfQsJQwgchIBam+LcZsg=</xenc:CipherValue></xenc:CipherData></xenc:EncryptedKey></dsig:KeyInfo>;
<xenc:CipherData>
<xenc:CipherValue>Ue78tQz5yJ17WGHynbAAJj6+07i4ui7meEJHEOBdME9zNLtcKOUt4pBecheWCigrWrcAptMuX+G9LYbD6cxgNdyImM4wTAWBOQo+taFeWUw=</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedData></saml:EncryptedID>
<samlp:SessionIndex>SAMLY2lib_assert_81deeaa5da2a8c679ce8a93ef4f9ef556d8bf35355ab38b1</samlp:SessionIndex>
</samlp:LogoutRequest>
The software is configured to sign the requests and to mir it seems
that they are.
The second one is:
2019-11-19T15:14:42,933 [qtp625170225-82314] TRACE unity.server.saml.SamlHttpServlet: Got SAML request using the HTTP Redirect binding:
<samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_bfd05bb0a78d8665d76c81906c6b4df516e7de2314" Version="2.0" IssueInstant="2019-11-19T14:14:42Z" Destination="https://b2access.eudat.eu/saml-idp/SLO-WEB"><saml:Issuer>https://aai.eosc-portal.eu/proxy/module.php/saml/sp/metadata.php/sso</saml:Issuer><saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">a7e5201a-8e97-449f-a32b-f128cc1186d3</saml:NameID><samlp:SessionIndex>SAMLY2lib_assert_34e6e470d7b9a27d769bbf0fd3ca9780697c666cfd24c055</samlp:SessionIndex></samlp:LogoutRequest>
2019-11-19T15:14:42,936 [qtp625170225-82314] DEBUG unity.server.saml.SLOAsyncResponseHandler: SAML error is going to be returned to the SAML requester from SLO endpoint
eu.unicore.samly2.exceptions.SAMLRequesterException: SAML document is not signed and the policy requires a signature
To me it looks like the signature is really missing, although the admin
says it is sigend.
Do you have some ideas?
Cheers,
Sander
On Tue, 2019-11-12 at 09:54 +0100, Krzysztof Benedyczak wrote:
> Shiraz,
>
> Please enable dumping of raw messages during deciphering. This is a
> library logging:
>
> <Logger name="unicore.security" level="TRACE"/>
>
> and the deciphered request is what we need, so should be before what
> you pasted.
>
> HTH
> KB
>
> W dniu 08.11.2019 o 14:37, Shiraz Memon pisze:
> > Hi,
> >
> > The saml log is already configured to trace level.
> >
> > </xenc:CipherData></xenc:EncryptedData></saml:EncryptedID><samlp:Se
> > ssionIndex>SAMLY2lib_assert_a3a85c9524c1fa67b7ccce8c40ffb89c175e85a
> > 49058231b</samlp:SessionIndex></samlp:LogoutRequest>
> > 2019-11-08T14:34:15,788 [qtp1417465-7314] DEBUG
> > unity.server.saml.SLOAsyncResponseHandler: SAML error
> > is going to be returned to the SAML requester from
> > SLO endpoint
> > eu.unicore.samly2.exceptions.SAMLRequesterException: Logged out
> > entity name must be present in SLO request and only NameID is
> > supported
> > at
> > eu.unicore.samly2.validators.LogoutRequestValidator.validateSubject
> > (LogoutRequestValidator.java:64) ~[samly2-2.3.3.jar:2.3.3]
> > at
> > eu.unicore.samly2.validators.LogoutRequestValidator.validate(Logout
> > RequestValidator.java:35) ~[samly2-2.3.3.jar:2.3.3]
> > at
> > pl.edu.icm.unity.saml.slo.SAMLLogoutProcessor.resolveRequest(SAMLLo
> > goutProcessor.java:364) ~[unity-server-saml-2.8.2.jar:?]
> > at
> > pl.edu.icm.unity.saml.slo.SAMLLogoutProcessor.initFromSAML(SAMLLogo
> > utProcessor.java:256) [unity-server-saml-2.8.2.jar:?]
> > at
> > pl.edu.icm.unity.saml.slo.SAMLLogoutProcessor.handleAsyncLogoutFrom
> > SAML(SAMLLogoutProcessor.java:165) [unity-server-saml-2.8.2.jar:?]
> > at
> > pl.edu.icm.unity.saml.slo.SLOSAMLServlet.postProcessRequest(SLOSAML
> > Servlet.java:44) [unity-server-saml-2.8.2.jar:?]
> > at
> > pl.edu.icm.unity.saml.SamlHttpServlet.process(SamlHttpServlet.java:
> > 100) [unity-server-saml-2.8.2.jar:?]
> > at
> > pl.edu.icm.unity.saml.SamlHttpServlet.doGet(SamlHttpServlet.java:46
> > ) [unity-server-saml-2.8.2.jar:?]
> > at
> > javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> > [javax.servlet-api-3.1.0.jar:3.1.0]
> > at
> > javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> > [javax.servlet-api-3.1.0.jar:3.1.0]
> > at
> > org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:8
> > 67) [jetty-servlet-9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(Servl
> > etHandler.java:1623) [jetty-servlet-
> > 9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > pl.edu.icm.unity.webui.authn.InvocationContextSetupFilter.doFilter(
> > InvocationContextSetupFilter.java:74) [unity-server-
> > web-common-2.8.2.jar:?]
> > at
> > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(Servl
> > etHandler.java:1610) [jetty-servlet-
> > 9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > pl.edu.icm.unity.webui.authn.AuthenticationFilter.gotoNotProtectedR
> > esource(AuthenticationFilter.java:266) [unity-server-web-common-
> > 2.8.2.jar:?]
> > at
> > pl.edu.icm.unity.webui.authn.AuthenticationFilter.handleNotProtecte
> > dResource(AuthenticationFilter.java:104) [unity-server-web-common-
> > 2.8.2.jar:?]
> > at
> > pl.edu.icm.unity.webui.authn.AuthenticationFilter.doFilter(Authenti
> > cationFilter.java:81) [unity-server-web-common-2.8.2.jar:?]
> > at
> > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(Servl
> > etHandler.java:1610) [jetty-servlet-
> > 9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > pl.edu.icm.unity.engine.api.utils.HiddenResourcesFilter.doFilter(Hi
> > ddenResourcesFilter.java:49) [unity-server-engine-api-2.8.2.jar:?]
> > at
> > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(Servl
> > etHandler.java:1610) [jetty-servlet-
> > 9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.ja
> > va:540) [jetty-servlet-9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHan
> > dler.java:255) [jetty-server-
> > 9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHan
> > dler.java:1588) [jetty-server-
> > 9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHan
> > dler.java:255) [jetty-server-
> > 9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHan
> > dler.java:1345) [jetty-server-
> > 9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHand
> > ler.java:203) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.jav
> > a:480) [jetty-servlet-9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHand
> > ler.java:1557) [jetty-server-
> > 9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHand
> > ler.java:201) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHand
> > ler.java:1247) [jetty-server-
> > 9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler
> > .java:144) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapp
> > er.java:132) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > pl.edu.icm.unity.engine.server.ClientIPSettingHandler.handle(Client
> > IPSettingHandler.java:58) [unity-server-engine-2.8.2.jar:?]
> > at
> > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(Co
> > ntextHandlerCollection.java:220) [jetty-server-
> > 9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapp
> > er.java:132) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHand
> > ler.java:335) [jetty-rewrite-
> > 9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandle
> > r.java:753) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapp
> > er.java:132) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
> > at org.eclipse.jetty.server.Server.handle(Server.java:502)
> > [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > pl.edu.icm.unity.engine.server.JettyServer$1.handle(JettyServer.jav
> > a:215) [unity-server-engine-2.8.2.jar:?]
> > at
> > org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)
> > [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.j
> > ava:260) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(Abst
> > ractConnection.java:305) [jetty-io-
> > 9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> > [jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable
> > (SslConnection.java:411) [jetty-io-
> > 9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.jav
> > a:305) [jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.ja
> > va:159) [jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> > [jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118
> > ) [jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWh
> > atYouKill.java:333) [jetty-util-
> > 9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(Eat
> > WhatYouKill.java:310) [jetty-util-
> > 9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(Ea
> > tWhatYouKill.java:168) [jetty-util-
> > 9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYo
> > uKill.java:126) [jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread
> > .run(ReservedThreadExecutor.java:366) [jetty-util-
> > 9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadP
> > ool.java:765) [jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
> > at
> > org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPo
> > ol.java:683) [jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
> > at java.lang.Thread.run(Thread.java:748) [?:1.8.0_222]
> > 2019-11-08T14:34:15,789 [qtp1417465-7314] DEBUG
> > unity.server.saml.ResponseHandlerBase: Returning Logout Error
> > SAMLResponse with HTTP Redirect binding to
> > https://test.ggus.eu/Shibboleth.sso/SLO/Redirect
> > 2019-11-08T14:34:15,790 [qtp1417465-7314] TRACE
> > unity.server.saml.ResponseHandlerBase: SAML
> > SAMLResponse is:
> > <urn:LogoutResponse IssueInstant="2019-11-08T13:34:15.789Z"
> > ID="SAMLY2lib_msg_e22ca2eb2cd0014ac9c34617b52b836eebb6141762df2bcf"
> > Version="2.0" InResponseTo="_cdeb6c41e0e34221ccba36ec18db2d84"
> > xmlns:urn="urn:oasis:names:tc:SAML:2.0:protocol"><urn1:Issuer
> > Format="" xmlns:urn1="urn:oasis:names:tc:SAML:2.0:assertion">
> > https://unity.eudat-aai.fz-juelich.de:8443/saml-
> > idp/metadata</urn1:Issuer><urn:Status><urn:StatusCode
> > Value="urn:oasis:names:tc:SAML:2.0:status:Requester"/><urn:StatusMe
> > ssage>Logged out entity name must be present in SLO request and
> > only NameID is
> > supported</urn:StatusMessage></urn:Status></urn:LogoutResponse>
> > 2019-11-08T14:34:15,790 [qtp1417465-7314] TRACE
> > unity.server.saml.ResponseHandlerBase: Returned
> > Redirect URL is:
> >
https://test.ggus.eu/Shibboleth.sso/SLO/Redirect?SAMLResponse=fZJbaxsxEEb%2FyqD3vUi7Wa%2BFbSgNBYPTQhwC7YvRZexs2ZW2Ggma%2FvrKbgPbPuRNGkZnzsdok4KTB3%2FxKT4izd4Rwp4o4d5RVC5umaj5uuC8qPsn3simlfyuXPXrbwz291t2%2FPBw%2BCrGQZ8mupxQCKMEamFsXfNWmbVp2o6v9J3QfdMhat3xlq86Yc9CmzODZww0eJfHlHUmujeJJ79lJ2NRd6blWGPTCsGN0SpTDO%2BtFrZvGfycRkcyZ9iyaxCvaCDp1IQko5FXOZnBcg4%2BeuNHttvk
> > Ni5vCQN88mFSOeKCw98HKSIMMQuz3UuMM8mqSm6IryUmq2Kh1FCefxXfE46DeSktyr5
> > tm4rUNBaDnasJo8p9alMtNG5O8hhVTLQ8f%2FQW4VmNCd93olu3fMQfCSliYNWS8oBE
> > 6oK7vOMLWsh7BnQxK8OVBFOiCBphDki5DoOD4%2BELhD8wUC4%2FceMrfM7N%2B3sYC
> > CjNsw8R7S3Ef1OWtb%2BXfz%2FX7jc%3D
> >
> > Cheers,
> > Shiraz
> >
> > On Fri, Nov 8, 2019 at 9:44 AM Krzysztof Benedyczak <
> > kb...@un...> wrote:
> > > Hi Shiraz,
> > >
> > > W dniu 06.11.2019 o 13:00, Shiraz Memon pisze:
> > > > Hi Krzysztof,
> > > >
> > > > I have configured an SP, which is based on shibboleth. I can
> > > > successfully sign-in but unfortunately I cannot log-out (SLO).
> > > > Below are the SLO request and response messages from sp and
> > > > unity respectively, and also the SP configuration in unity.
> > > > <?xml
> > > > version="1.0"
> > > > encoding="UTF-8"?>
> > > > <samlp:LogoutRequest
> > > > xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
> > > > Destination="
> > > > https://unity.eudat-aai.fz-juelich.de/saml-idp/SLO-WEB"
> > > > ID="_56f68d31d948b0ccc241c0efe0697d36"
> > > > IssueInstant="2019-11-06T11:17:58Z"
> > > > Version="2.0">
> > > > <saml:Issuer
> > > > xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
> > > > https://test.ggus.eu/EOSC-hub/secure</saml:Issuer>;
> > > > <samlp:Extensions>
> > > > <aslo:Asynchronous
> > > > xmlns:aslo="urn:oasis:names:tc:SAML:2.0:protocol:ext:async-slo"
> > > > />
> > > > </samlp:Extensions>
> > > > <saml:EncryptedID
> > > > xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
> > > > <xenc:EncryptedData
> > > > xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
> > > > Type="http://www.w3.org/2001/04/xmlenc#Element">;
> > > > <xenc:EncryptionMethod
> > > > Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" />
> > > > <ds:KeyInfo
> > > > xmlns:ds="http://www.w3.org/2000/09/xmldsig#">;
> > > > <xenc:EncryptedKey>
> > > > <xenc:EncryptionMethod
> > > > Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p" />
> > > > <xenc:CipherData>
> > > > <xenc:CipherValue>S/GMplTHJ2N0vbOVMhyUK8bBTNriupFbp12wwnvUmioEj
> > > > x5xpBhYGYgEF5IQChVm66GdgIJ8czAk
> > > > RX1HbwqOGUktGocmR+Fcxq9wn5OSrQ4i/mj4kIF+aqlh8+bir2gua5XLd16DPn
> > > > 61CM3bUv2HWfNK
> > > > P0IAO3D77ezdJ+DR4jZ5wEfqZE3+OFplfMyzc2s7w4iswSs/cs/3fXJzkSFKGUP
> > > > 32P50izi4HxBg
> > > > eN7F7knsFHiD8P0b62btMOUQCHHG6LG9U7Esfjwe+uO88wJEmge295FQWRwJHvr
> > > > bO8O7rEwnDu8+
> > > > 1d1/Vnb0OT5lvM0E8sC/LYUKpO62DHjUvVI60BQ2/6NJPVsTjV4CEp77nQK7aR6
> > > > dmJaVxlFJ2EZw
> > > > cD3s49RPazXpATvAPLrg/0t2lLFIB/Z5g8AX+5FqBn1vkqrYpKQoBdnTjO/j5L
> > > > GYbs8q9s2/HlP9
> > > > 4Mf9iCW9YOCV1Q8KOLAvgLHJWKCVHNQQARTIHHN2ocX2jNWiWf0zaG/1sEW8KP6
> > > > uOyoLpnTQ9YB6
> > > > I81yndVV+YXVWQYLk7wrUB2KPXVHCEshjmHzwJxhvWvIQYrvpBuLOLfAjShNpFs
> > > > Hyn/yCBBs5LdE
> > > > RlDAdcKkikAQO5MkJjcLSkY0Jh3C5PAJ+jPhjZ5Lv9z1+VuJabb9lpLCNAI8Lx0
> > > > dYJ7LbExv8Gw=</xenc:CipherValue>
> > > > </xenc:CipherData>
> > > > </xenc:EncryptedKey>
> > > > </ds:KeyInfo>
> > > > <xenc:CipherData>
> > > > <xenc:CipherValue>uwTdWX75kV+KaSwdLSY0miFxW7oaIEqIpUF9LTZgYEsgH
> > > > zh6lQeJs0trR9CzTF6+b8/+j8mpCCkF
> > > > 6BsHJcikJRZySAo2THBfZlTk1FIcOXgOMW6U2k3loUSxr6JT1mXFXXCBkUeraP
> > > > 38JJ62Yg9GMGFd
> > > > DYKNtbTI2fuK6Z8TwBwK/lDeJ+atIOcnTT8AKBYXpo0Ni/s+0XivyecXPKdkYIR
> > > > Sh34u9nZ2DVr0 ENrgpmXR1X+hctYU7NeRgEFjQjCf</xenc:CipherValue>
> > > > </xenc:CipherData>
> > > > </xenc:EncryptedData>
> > > > </saml:EncryptedID>
> > > > <samlp:SessionIndex>SAMLY2lib_assert_fd9a89a3fa593431e7c87fc612
> > > > 66a55d5b3b64d8ea7f6bc3</samlp:SessionIndex>
> > > > </samlp:LogoutRequest>
> > > >
> > > > <?xml version="1.0" encoding="UTF-8"?>
> > > > <urn:LogoutResponse
> > > > xmlns:urn="urn:oasis:names:tc:SAML:2.0:protocol"
> > > > IssueInstant="2019-11-06T11:33:04.725Z"
> > > > ID="SAMLY2lib_msg_64b9f960635a040fc79f7707675d67b026020087543ab
> > > > 8f8"
> > > > Version="2.0"
> > > > InResponseTo="_4d31d3d8048d719329c6c5f43c35fb39">
> > > > <urn1:Issuer
> > > > xmlns:urn1="urn:oasis:names:tc:SAML:2.0:assertion"
> > > > Format="">
> > > > https://unity.eudat-aai.fz-juelich.de:8443/saml-idp/metadata</urn1:Issuer>
> > > > ;
> > > > <urn:Status>
> > > > <urn:StatusCode
> > > > Value="urn:oasis:names:tc:SAML:2.0:status:Requester" />
> > > > <urn:StatusMessage>Logged
> > > > out entity name must be present in SLO request and only NameID
> > > > is supported</urn:StatusMessage>
> > > > </urn:Status>
> > > > </urn:LogoutResponse>
> > > >
> > >
> > > Looks like some incompatibility on what is sent to Unity in
> > > logout request, as a subject to be logged out. I can't say more
> > > as the request is encrypted.
> > > If you enable trace logging you should be able to see decrypted
> > > message in log, then we can say more. Looks like the subject
> > > (i.e. the one to be logged out) is provided in some of
> > > unsupported ways to unity. I suppose this was not working with
> > > older unity version too, right? And even if it was most likely
> > > the triggering is on the client side.
> > > Best,
> > > Krzysztof
> > >
> >
> >
> > --
> > 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 Volker Rieke
> > Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt
> > (Vorsitzender),
> > Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
> > Prof. Dr. Sebastian M. Schmidt
> > -----------------------------------------------------------------
> > -------------------------------
> > -----------------------------------------------------------------
> > -------------------------------
> >
>
> _______________________________________________
> Unity-idm-discuss mailing list
> Uni...@li...
> https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss
--
Federated Systems and Data
Juelich Supercomputing Centre
phone: +49 2461 61 8847
fax: +49 2461 61 6656
email: sa....@fz...
----------------------------------------------------------------------
-----------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Volker Rieke
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
-----------------------------------------------------------------------
-----------------------------------------------------------------------
|
|
From: Sander A. <sa....@fz...> - 2019-11-18 08:08:09
|
Hi Krzysztof, I guessed that it is not possible. Thank you very much for your investigation to this. Best regards, Sander On Mon, 2019-11-18 at 09:03 +0100, Krzysztof Benedyczak wrote: > Hi Sander, > > W dniu 12.11.2019 o 11:51, Sander Apweiler pisze: > > > If I understood this correctly those are basically two > > > federations > > > (two > > > XMLs with metadata) Basic and Advanced, in Advanced I'll find all > > > IdPs > > > from Basic (same SAML entityIds), right? > > > > > > If so how do you envision a choice which one is going to be used > > > for > > > authentication of a user who happens to be in IdP which is member > > > of > > > both? There should be a choice (so user can select) or simply > > > always > > > use > > > the advanced one? > > > > If the IdP is part of the advanced class, it should be always used > > the > > advanced. There should be no user selection, because user will > > always > > end at the same IdP. > > I had to verify what the answer is. > > So unfortunately this won't work in reliable way: there is no way > currently in Unity to specify which SAML metadata is overriding > another > one. Actually the picture is quite complex as also in Unity you can > define manually (not via metadata) your trusted IdPs. Those guys are > guaranteed to take precedence over all metadata based, but entries > are > actually merged. I.e. if metadata brings more details about IdP it > will > be added to the manually defined one, but no setting will be > changed. > However wrt to the order of metadata provided IdPs there are no ways > to > control it - the first one will win, but is rather random which one > becomes the first. > > Best, > Krzysztof > > -- Federated Systems and Data Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ---------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Volker Rieke Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Krzysztof B. <kb...@un...> - 2019-11-18 08:03:54
|
Hi Sander, W dniu 12.11.2019 o 11:51, Sander Apweiler pisze: >> If I understood this correctly those are basically two federations >> (two >> XMLs with metadata) Basic and Advanced, in Advanced I'll find all >> IdPs >> from Basic (same SAML entityIds), right? >> >> If so how do you envision a choice which one is going to be used for >> authentication of a user who happens to be in IdP which is member of >> both? There should be a choice (so user can select) or simply always >> use >> the advanced one? > If the IdP is part of the advanced class, it should be always used the > advanced. There should be no user selection, because user will always > end at the same IdP. I had to verify what the answer is. So unfortunately this won't work in reliable way: there is no way currently in Unity to specify which SAML metadata is overriding another one. Actually the picture is quite complex as also in Unity you can define manually (not via metadata) your trusted IdPs. Those guys are guaranteed to take precedence over all metadata based, but entries are actually merged. I.e. if metadata brings more details about IdP it will be added to the manually defined one, but no setting will be changed. However wrt to the order of metadata provided IdPs there are no ways to control it - the first one will win, but is rather random which one becomes the first. Best, Krzysztof |
|
From: Krzysztof B. <kb...@un...> - 2019-11-12 22:41:22
|
W dniu 12.11.2019 o 15:32, Sander Apweiler pisze: > Hi Krzysztof, > > we have a small issue. We have two different Attributes with > entitlement information. One with our local ones and one with the > information from IdP. We want to combine this information in the output > translation profile. A simple + operator does of course not work with > arrays. Do you have another solution? This is bit verbose, but ensures that the source data structures are not modified. Also I guess there is simpler way to do this in MVEL, but this will work without much thinking on my end :-) Assumes that you are combining attr1 values with attr2 values. combined = new java.util.ArrayList(); combined.addAll(attrs['attr1']); combined.addAll(attrs['attr2']); return combined; Cheers, KB |
|
From: Krzysztof B. <kb...@un...> - 2019-11-12 20:33:32
|
Dear Subscribers, A new release is ready for download <https://www.unity-idm.eu/downloads/>, bringing two new features: * selective JSON DB dumps (and restores!) * super-fast multi group REST API queries What's more a lot of bugfixes over the 3.0.0 release is included, including some important ones, as replacement of buggy jetty (http server) library used in Unity 3.0. This is a drop in replacement over 3.0.0, neither DB migration nor config file changes are needed. Happy installing, Krzysztof |
|
From: Sander A. <sa....@fz...> - 2019-11-12 14:33:06
|
Hi Krzysztof, we have a small issue. We have two different Attributes with entitlement information. One with our local ones and one with the information from IdP. We want to combine this information in the output translation profile. A simple + operator does of course not work with arrays. Do you have another solution? We want to separate the local and remote information. For this reason we want to avoid storing both on the same internal attribute. Cheers, Sander -- Federated Systems and Data Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ---------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Volker Rieke Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Sander A. <sa....@fz...> - 2019-11-12 10:51:32
|
Hi Krzysztof, On Tue, 2019-11-12 at 10:15 +0100, Krzysztof Benedyczak wrote: > Hi Sander, > > W dniu 11.11.2019 o 14:48, Sander Apweiler pisze: > > Hi Krzysztof, > > > > the DFN AAI offers different trust levels for the IdP federation > > based > > on the identity vetting. Every IdP is in the basic one but not all > > are > > in the advanced one (higher identity vetting). If we want to > > support > > both federations, unity will find IdPs two times. One in basic and > > one > > in advanced. > > > > We want to store some Assurance information to the users, based on > > the > > federation. Because the users of an IdP from DFN advanced have a > > high > > identity vetting instead of basic AAI. I assume we would need two > > different input translation profiles for it. Please correct me if I > > am > > wrong. > > > > So I have two different questions. > > 1. Can unity deal with the fact that IdPs are listed two times and > > using different translation profiles? > > 2. If 1 is yes, who we could ensure that IdPs from advanced AAI are > > always uses the path trough advanced and never trough the basic > > AAI? > > If I understood this correctly those are basically two federations > (two > XMLs with metadata) Basic and Advanced, in Advanced I'll find all > IdPs > from Basic (same SAML entityIds), right? > > If so how do you envision a choice which one is going to be used for > authentication of a user who happens to be in IdP which is member of > both? There should be a choice (so user can select) or simply always > use > the advanced one? If the IdP is part of the advanced class, it should be always used the advanced. There should be no user selection, because user will always end at the same IdP. Cheers, Sander > > Best, > Krzysztof > -- Federated Systems and Data Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ---------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Volker Rieke Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Marcus H. <ha...@ki...> - 2019-11-12 09:44:03
|
On 11/12/19 10:15, Krzysztof Benedyczak wrote: > Hi Sander, > > W dniu 11.11.2019 o 14:48, Sander Apweiler pisze: > > Hi Krzysztof, > > > > the DFN AAI offers different trust levels for the IdP federation based > > on the identity vetting. Every IdP is in the basic one but not all are > > in the advanced one (higher identity vetting). If we want to support > > both federations, unity will find IdPs two times. One in basic and one > > in advanced. > > > > We want to store some Assurance information to the users, based on the > > federation. Because the users of an IdP from DFN advanced have a high > > identity vetting instead of basic AAI. I assume we would need two > > different input translation profiles for it. Please correct me if I am > > wrong. > > > > So I have two different questions. > > 1. Can unity deal with the fact that IdPs are listed two times and > > using different translation profiles? > > 2. If 1 is yes, who we could ensure that IdPs from advanced AAI are > > always uses the path trough advanced and never trough the basic AAI? > > If I understood this correctly those are basically two federations (two XMLs > with metadata) Basic and Advanced, in Advanced I'll find all IdPs from Basic > (same SAML entityIds), right? Otherway round: All the advanced IdPs are also in Basic. > If so how do you envision a choice which one is going to be used for > authentication of a user who happens to be in IdP which is member of both? > There should be a choice (so user can select) or simply always use the > advanced one? It's the same entity ID. I.e. our IdP qualifies for Advanced. Therefore it is in Advanced. But therefore the same entity is also in Basic. -- Marcus. |
|
From: Krzysztof B. <kb...@un...> - 2019-11-12 09:38:44
|
W dniu 12.11.2019 o 10:22, Marcus Hardt pisze: > On 11/12/19 10:15, Krzysztof Benedyczak wrote: >> Hi Sander, >> >> W dniu 11.11.2019 o 14:48, Sander Apweiler pisze: >>> Hi Krzysztof, >>> >>> the DFN AAI offers different trust levels for the IdP federation based >>> on the identity vetting. Every IdP is in the basic one but not all are >>> in the advanced one (higher identity vetting). If we want to support >>> both federations, unity will find IdPs two times. One in basic and one >>> in advanced. >>> >>> We want to store some Assurance information to the users, based on the >>> federation. Because the users of an IdP from DFN advanced have a high >>> identity vetting instead of basic AAI. I assume we would need two >>> different input translation profiles for it. Please correct me if I am >>> wrong. >>> >>> So I have two different questions. >>> 1. Can unity deal with the fact that IdPs are listed two times and >>> using different translation profiles? >>> 2. If 1 is yes, who we could ensure that IdPs from advanced AAI are >>> always uses the path trough advanced and never trough the basic AAI? >> If I understood this correctly those are basically two federations (two XMLs >> with metadata) Basic and Advanced, in Advanced I'll find all IdPs from Basic >> (same SAML entityIds), right? > Otherway round: All the advanced IdPs are also in Basic. Yes, sure - typo. |
|
From: Krzysztof B. <kb...@un...> - 2019-11-12 09:15:21
|
Hi Sander, W dniu 11.11.2019 o 14:48, Sander Apweiler pisze: > Hi Krzysztof, > > the DFN AAI offers different trust levels for the IdP federation based > on the identity vetting. Every IdP is in the basic one but not all are > in the advanced one (higher identity vetting). If we want to support > both federations, unity will find IdPs two times. One in basic and one > in advanced. > > We want to store some Assurance information to the users, based on the > federation. Because the users of an IdP from DFN advanced have a high > identity vetting instead of basic AAI. I assume we would need two > different input translation profiles for it. Please correct me if I am > wrong. > > So I have two different questions. > 1. Can unity deal with the fact that IdPs are listed two times and > using different translation profiles? > 2. If 1 is yes, who we could ensure that IdPs from advanced AAI are > always uses the path trough advanced and never trough the basic AAI? If I understood this correctly those are basically two federations (two XMLs with metadata) Basic and Advanced, in Advanced I'll find all IdPs from Basic (same SAML entityIds), right? If so how do you envision a choice which one is going to be used for authentication of a user who happens to be in IdP which is member of both? There should be a choice (so user can select) or simply always use the advanced one? Best, Krzysztof |
|
From: Krzysztof B. <kb...@un...> - 2019-11-12 08:55:04
|
Shiraz, Please enable dumping of raw messages during deciphering. This is a library logging: <Logger name="unicore.security" level="TRACE"/> and the deciphered request is what we need, so should be before what you pasted. HTH KB W dniu 08.11.2019 o 14:37, Shiraz Memon pisze: > Hi, > > The saml log is already configured to trace level. > > </xenc:CipherData></xenc:EncryptedData></saml:EncryptedID><samlp:SessionIndex>SAMLY2lib_assert_a3a85c9524c1fa67b7ccce8c40ffb89c175e85a49058231b</samlp:SessionIndex></samlp:LogoutRequest> > > 2019-11-08T14:34:15,788 [qtp1417465-7314] DEBUG > unity.server.saml.SLOAsyncResponseHandler: SAML error is going to be > returned to the SAML requester from SLO endpoint > eu.unicore.samly2.exceptions.SAMLRequesterException: Logged out entity > name must be present in SLO request and only NameID is supported > at > eu.unicore.samly2.validators.LogoutRequestValidator.validateSubject(LogoutRequestValidator.java:64) > ~[samly2-2.3.3.jar:2.3.3] > at > eu.unicore.samly2.validators.LogoutRequestValidator.validate(LogoutRequestValidator.java:35) > ~[samly2-2.3.3.jar:2.3.3] > at > pl.edu.icm.unity.saml.slo.SAMLLogoutProcessor.resolveRequest(SAMLLogoutProcessor.java:364) > ~[unity-server-saml-2.8.2.jar:?] > at > pl.edu.icm.unity.saml.slo.SAMLLogoutProcessor.initFromSAML(SAMLLogoutProcessor.java:256) > [unity-server-saml-2.8.2.jar:?] > at > pl.edu.icm.unity.saml.slo.SAMLLogoutProcessor.handleAsyncLogoutFromSAML(SAMLLogoutProcessor.java:165) > [unity-server-saml-2.8.2.jar:?] > at > pl.edu.icm.unity.saml.slo.SLOSAMLServlet.postProcessRequest(SLOSAMLServlet.java:44) > [unity-server-saml-2.8.2.jar:?] > at > pl.edu.icm.unity.saml.SamlHttpServlet.process(SamlHttpServlet.java:100) > [unity-server-saml-2.8.2.jar:?] > at > pl.edu.icm.unity.saml.SamlHttpServlet.doGet(SamlHttpServlet.java:46) > [unity-server-saml-2.8.2.jar:?] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) > [javax.servlet-api-3.1.0.jar:3.1.0] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > [javax.servlet-api-3.1.0.jar:3.1.0] > at > org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:867) > [jetty-servlet-9.4.14.v20181114.jar:9.4.14.v20181114] > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1623) > [jetty-servlet-9.4.14.v20181114.jar:9.4.14.v20181114] > at > pl.edu.icm.unity.webui.authn.InvocationContextSetupFilter.doFilter(InvocationContextSetupFilter.java:74) > [unity-server-web-common-2.8.2.jar:?] > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610) > [jetty-servlet-9.4.14.v20181114.jar:9.4.14.v20181114] > at > pl.edu.icm.unity.webui.authn.AuthenticationFilter.gotoNotProtectedResource(AuthenticationFilter.java:266) > [unity-server-web-common-2.8.2.jar:?] > at > pl.edu.icm.unity.webui.authn.AuthenticationFilter.handleNotProtectedResource(AuthenticationFilter.java:104) > [unity-server-web-common-2.8.2.jar:?] > at > pl.edu.icm.unity.webui.authn.AuthenticationFilter.doFilter(AuthenticationFilter.java:81) > [unity-server-web-common-2.8.2.jar:?] > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610) > [jetty-servlet-9.4.14.v20181114.jar:9.4.14.v20181114] > at > pl.edu.icm.unity.engine.api.utils.HiddenResourcesFilter.doFilter(HiddenResourcesFilter.java:49) > [unity-server-engine-api-2.8.2.jar:?] > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610) > [jetty-servlet-9.4.14.v20181114.jar:9.4.14.v20181114] > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) > [jetty-servlet-9.4.14.v20181114.jar:9.4.14.v20181114] > at > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) > [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114] > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588) > [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114] > at > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) > [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114] > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345) > [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114] > at > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) > [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114] > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480) > [jetty-servlet-9.4.14.v20181114.jar:9.4.14.v20181114] > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557) > [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114] > at > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) > [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114] > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247) > [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114] > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) > [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114] > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) > [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114] > at > pl.edu.icm.unity.engine.server.ClientIPSettingHandler.handle(ClientIPSettingHandler.java:58) > [unity-server-engine-2.8.2.jar:?] > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220) > [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114] > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) > [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114] > at > org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335) > [jetty-rewrite-9.4.14.v20181114.jar:9.4.14.v20181114] > at > org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:753) > [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114] > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) > [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114] > at org.eclipse.jetty.server.Server.handle(Server.java:502) > [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114] > at > pl.edu.icm.unity.engine.server.JettyServer$1.handle(JettyServer.java:215) > [unity-server-engine-2.8.2.jar:?] > at > org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364) > [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114] > at > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260) > [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114] > at > org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305) > [jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114] > at > org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) > [jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114] > at > org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:411) > [jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114] > at > org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:305) > [jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114] > at > org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159) > [jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114] > at > org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) > [jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114] > at > org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118) > [jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114] > at > org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333) > [jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114] > at > org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310) > [jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114] > at > org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168) > [jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114] > at > org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126) > [jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114] > at > org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366) > [jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114] > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765) > [jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114] > at > org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683) > [jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114] > at java.lang.Thread.run(Thread.java:748) [?:1.8.0_222] > 2019-11-08T14:34:15,789 [qtp1417465-7314] DEBUG > unity.server.saml.ResponseHandlerBase: Returning Logout Error > SAMLResponse with HTTP Redirect binding to > https://test.ggus.eu/Shibboleth.sso/SLO/Redirect > 2019-11-08T14:34:15,790 [qtp1417465-7314] TRACE > unity.server.saml.ResponseHandlerBase: SAML SAMLResponse is: > <urn:LogoutResponse IssueInstant="2019-11-08T13:34:15.789Z" > ID="SAMLY2lib_msg_e22ca2eb2cd0014ac9c34617b52b836eebb6141762df2bcf" > Version="2.0" InResponseTo="_cdeb6c41e0e34221ccba36ec18db2d84" > xmlns:urn="urn:oasis:names:tc:SAML:2.0:protocol"><urn1:Issuer > Format="" > xmlns:urn1="urn:oasis:names:tc:SAML:2.0:assertion">https://unity.eudat-aai.fz-juelich.de:8443/saml- > idp/metadata</urn1:Issuer><urn:Status><urn:StatusCode > Value="urn:oasis:names:tc:SAML:2.0:status:Requester"/><urn:StatusMessage>Logged > out entity name must be present in SLO request and only NameID is > supported</urn:StatusMessage></urn:Status></urn:LogoutResponse> > 2019-11-08T14:34:15,790 [qtp1417465-7314] TRACE > unity.server.saml.ResponseHandlerBase: Returned Redirect URL is: > https://test.ggus.eu/Shibboleth.sso/SLO/Redirect?SAMLResponse=fZJbaxsxEEb%2FyqD3vUi7Wa%2BFbSgNBYPTQhwC7YvRZexs2ZW2Ggma%2FvrKbgPbPuRNGkZnzsdok4KTB3%2FxKT4izd4Rwp4o4d5RVC5umaj5uuC8qPsn3simlfyuXPXrbwz291t2%2FPBw%2BCrGQZ8mupxQCKMEamFsXfNWmbVp2o6v9J3QfdMhat3xlq86Yc9CmzODZww0eJfHlHUmujeJJ79lJ2NRd6blWGPTCsGN0SpTDO%2BtFrZvGfycRkcyZ9iyaxCvaCDp1IQko5FXOZnBcg4%2BeuNHttvk > Ni5vCQN88mFSOeKCw98HKSIMMQuz3UuMM8mqSm6IryUmq2Kh1FCefxXfE46DeSktyr5tm4rUNBaDnasJo8p9alMtNG5O8hhVTLQ8f%2FQW4VmNCd93olu3fMQfCSliYNWS8oBE6oK7vOMLWsh7BnQxK8OVBFOiCBphDki5DoOD4%2BELhD8wUC4%2FceMrfM7N%2B3sYCCjNsw8R7S3Ef1OWtb%2BXfz%2FX7jc%3D > > Cheers, > Shiraz > > On Fri, Nov 8, 2019 at 9:44 AM Krzysztof Benedyczak <kb...@un... > <mailto:kb...@un...>> wrote: > > Hi Shiraz, > > W dniu 06.11.2019 o 13:00, Shiraz Memon pisze: >> Hi Krzysztof, >> >> I have configured an SP, which is based on shibboleth. I can >> successfully sign-in but unfortunately I cannot log-out (SLO). >> Below are the SLO request and response messages from sp and unity >> respectively, and also the SP configuration in unity. >> <?xml version="1.0"encoding="UTF-8"?> >> <samlp:LogoutRequest >> xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" >> Destination="https://unity.eudat-aai.fz-juelich.de/saml-idp/SLO-WEB" >> ID="_56f68d31d948b0ccc241c0efe0697d36" >> IssueInstant="2019-11-06T11:17:58Z" Version="2.0"><saml:Issuer >> xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://test.ggus.eu/EOSC-hub/secure</saml:Issuer><samlp:Extensions><aslo:Asynchronous >> xmlns:aslo="urn:oasis:names:tc:SAML:2.0:protocol:ext:async-slo" >> /></samlp:Extensions><saml:EncryptedID >> xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"><xenc:EncryptedData >> xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" >> Type="http://www.w3.org/2001/04/xmlenc#Element"><xenc:EncryptionMethod >> Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" >> /><ds:KeyInfo >> xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><xenc:EncryptedKey><xenc:EncryptionMethod >> Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p" >> /><xenc:CipherData><xenc:CipherValue>S/GMplTHJ2N0vbOVMhyUK8bBTNriupFbp12wwnvUmioEjx5xpBhYGYgEF5IQChVm66GdgIJ8czAk >> RX1HbwqOGUktGocmR+Fcxq9wn5OSrQ4i/mj4kIF+aqlh8+bir2gua5XLd16DPn61CM3bUv2HWfNK >> P0IAO3D77ezdJ+DR4jZ5wEfqZE3+OFplfMyzc2s7w4iswSs/cs/3fXJzkSFKGUP32P50izi4HxBg >> eN7F7knsFHiD8P0b62btMOUQCHHG6LG9U7Esfjwe+uO88wJEmge295FQWRwJHvrbO8O7rEwnDu8+ >> 1d1/Vnb0OT5lvM0E8sC/LYUKpO62DHjUvVI60BQ2/6NJPVsTjV4CEp77nQK7aR6dmJaVxlFJ2EZw >> cD3s49RPazXpATvAPLrg/0t2lLFIB/Z5g8AX+5FqBn1vkqrYpKQoBdnTjO/j5LGYbs8q9s2/HlP9 >> 4Mf9iCW9YOCV1Q8KOLAvgLHJWKCVHNQQARTIHHN2ocX2jNWiWf0zaG/1sEW8KP6uOyoLpnTQ9YB6 >> I81yndVV+YXVWQYLk7wrUB2KPXVHCEshjmHzwJxhvWvIQYrvpBuLOLfAjShNpFsHyn/yCBBs5LdE >> RlDAdcKkikAQO5MkJjcLSkY0Jh3C5PAJ+jPhjZ5Lv9z1+VuJabb9lpLCNAI8Lx0dYJ7LbExv8Gw=</xenc:CipherValue></xenc:CipherData></xenc:EncryptedKey></ds:KeyInfo><xenc:CipherData><xenc:CipherValue>uwTdWX75kV+KaSwdLSY0miFxW7oaIEqIpUF9LTZgYEsgHzh6lQeJs0trR9CzTF6+b8/+j8mpCCkF >> 6BsHJcikJRZySAo2THBfZlTk1FIcOXgOMW6U2k3loUSxr6JT1mXFXXCBkUeraP38JJ62Yg9GMGFd >> DYKNtbTI2fuK6Z8TwBwK/lDeJ+atIOcnTT8AKBYXpo0Ni/s+0XivyecXPKdkYIRSh34u9nZ2DVr0 >> ENrgpmXR1X+hctYU7NeRgEFjQjCf</xenc:CipherValue></xenc:CipherData></xenc:EncryptedData></saml:EncryptedID><samlp:SessionIndex>SAMLY2lib_assert_fd9a89a3fa593431e7c87fc61266a55d5b3b64d8ea7f6bc3</samlp:SessionIndex></samlp:LogoutRequest> >> >> <?xml version="1.0" encoding="UTF-8"?><urn:LogoutResponse >> xmlns:urn="urn:oasis:names:tc:SAML:2.0:protocol" >> IssueInstant="2019-11-06T11:33:04.725Z" >> ID="SAMLY2lib_msg_64b9f960635a040fc79f7707675d67b026020087543ab8f8" >> Version="2.0" >> InResponseTo="_4d31d3d8048d719329c6c5f43c35fb39"><urn1:Issuer >> xmlns:urn1="urn:oasis:names:tc:SAML:2.0:assertion" >> Format="">https://unity.eudat-aai.fz-juelich.de:8443/saml-idp/metadata</urn1:Issuer><urn:Status><urn:StatusCode >> Value="urn:oasis:names:tc:SAML:2.0:status:Requester" >> /><urn:StatusMessage>Logged out entity name must be present in >> SLO request and only NameID is >> supported</urn:StatusMessage></urn:Status></urn:LogoutResponse> >> > Looks like some incompatibility on what is sent to Unity in logout > request, as a subject to be logged out. I can't say more as the > request is encrypted. > > If you enable trace logging you should be able to see decrypted > message in log, then we can say more. Looks like the subject (i.e. > the one to be logged out) is provided in some of unsupported ways > to unity. I suppose this was not working with older unity version > too, right? And even if it was most likely the triggering is on > the client side. > > Best, > Krzysztof > > > > -- > 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 Volker Rieke > Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), > Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, > Prof. Dr. Sebastian M. Schmidt > ------------------------------------------------------------------------------------------------ > ------------------------------------------------------------------------------------------------ > |
|
From: Sander A. <sa....@fz...> - 2019-11-11 13:49:08
|
Hi Krzysztof, the DFN AAI offers different trust levels for the IdP federation based on the identity vetting. Every IdP is in the basic one but not all are in the advanced one (higher identity vetting). If we want to support both federations, unity will find IdPs two times. One in basic and one in advanced. We want to store some Assurance information to the users, based on the federation. Because the users of an IdP from DFN advanced have a high identity vetting instead of basic AAI. I assume we would need two different input translation profiles for it. Please correct me if I am wrong. So I have two different questions. 1. Can unity deal with the fact that IdPs are listed two times and using different translation profiles? 2. If 1 is yes, who we could ensure that IdPs from advanced AAI are always uses the path trough advanced and never trough the basic AAI? Best regards, Sander -- Federated Systems and Data Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ---------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Volker Rieke Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Shiraz M. <a....@fz...> - 2019-11-08 13:37:47
|
Hi,
The saml log is already configured to trace level.
</xenc:CipherData></xenc:EncryptedData></saml:EncryptedID><samlp:SessionIndex>SAMLY2lib_assert_a3a85c9524c1fa67b7ccce8c40ffb89c175e85a49058231b</samlp:SessionIndex></samlp:LogoutRequest>
2019-11-08T14:34:15,788 [qtp1417465-7314] DEBUG unity.server.saml.SLOAsyncResponseHandler: SAML error is going to be returned to the SAML requester from SLO endpoint
eu.unicore.samly2.exceptions.SAMLRequesterException: Logged out entity name must be present in SLO request and only NameID is supported
at eu.unicore.samly2.validators.LogoutRequestValidator.validateSubject(LogoutRequestValidator.java:64) ~[samly2-2.3.3.jar:2.3.3]
at eu.unicore.samly2.validators.LogoutRequestValidator.validate(LogoutRequestValidator.java:35) ~[samly2-2.3.3.jar:2.3.3]
at pl.edu.icm.unity.saml.slo.SAMLLogoutProcessor.resolveRequest(SAMLLogoutProcessor.java:364) ~[unity-server-saml-2.8.2.jar:?]
at pl.edu.icm.unity.saml.slo.SAMLLogoutProcessor.initFromSAML(SAMLLogoutProcessor.java:256) [unity-server-saml-2.8.2.jar:?]
at pl.edu.icm.unity.saml.slo.SAMLLogoutProcessor.handleAsyncLogoutFromSAML(SAMLLogoutProcessor.java:165) [unity-server-saml-2.8.2.jar:?]
at pl.edu.icm.unity.saml.slo.SLOSAMLServlet.postProcessRequest(SLOSAMLServlet.java:44) [unity-server-saml-2.8.2.jar:?]
at pl.edu.icm.unity.saml.SamlHttpServlet.process(SamlHttpServlet.java:100) [unity-server-saml-2.8.2.jar:?]
at pl.edu.icm.unity.saml.SamlHttpServlet.doGet(SamlHttpServlet.java:46) [unity-server-saml-2.8.2.jar:?]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) [javax.servlet-api-3.1.0.jar:3.1.0]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [javax.servlet-api-3.1.0.jar:3.1.0]
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:867) [jetty-servlet-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1623) [jetty-servlet-9.4.14.v20181114.jar:9.4.14.v20181114]
at pl.edu.icm.unity.webui.authn.InvocationContextSetupFilter.doFilter(InvocationContextSetupFilter.java:74) [unity-server-web-common-2.8.2.jar:?]
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610) [jetty-servlet-9.4.14.v20181114.jar:9.4.14.v20181114]
at pl.edu.icm.unity.webui.authn.AuthenticationFilter.gotoNotProtectedResource(AuthenticationFilter.java:266) [unity-server-web-common-2.8.2.jar:?]
at pl.edu.icm.unity.webui.authn.AuthenticationFilter.handleNotProtectedResource(AuthenticationFilter.java:104) [unity-server-web-common-2.8.2.jar:?]
at pl.edu.icm.unity.webui.authn.AuthenticationFilter.doFilter(AuthenticationFilter.java:81) [unity-server-web-common-2.8.2.jar:?]
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610) [jetty-servlet-9.4.14.v20181114.jar:9.4.14.v20181114]
at pl.edu.icm.unity.engine.api.utils.HiddenResourcesFilter.doFilter(HiddenResourcesFilter.java:49) [unity-server-engine-api-2.8.2.jar:?]
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610) [jetty-servlet-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) [jetty-servlet-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480) [jetty-servlet-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
at pl.edu.icm.unity.engine.server.ClientIPSettingHandler.handle(ClientIPSettingHandler.java:58) [unity-server-engine-2.8.2.jar:?]
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335) [jetty-rewrite-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:753) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.server.Server.handle(Server.java:502) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
at pl.edu.icm.unity.engine.server.JettyServer$1.handle(JettyServer.java:215) [unity-server-engine-2.8.2.jar:?]
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260) [jetty-server-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305) [jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) [jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:411) [jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:305) [jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159) [jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) [jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118) [jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333) [jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310) [jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168) [jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126) [jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366) [jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765) [jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683) [jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_222]
2019-11-08T14:34:15,789 [qtp1417465-7314] DEBUG unity.server.saml.ResponseHandlerBase: Returning Logout Error SAMLResponse with HTTP Redirect binding to https://test.ggus.eu/Shibboleth.sso/SLO/Redirect
2019-11-08T14:34:15,790 [qtp1417465-7314] TRACE unity.server.saml.ResponseHandlerBase: SAML SAMLResponse is:
<urn:LogoutResponse IssueInstant="2019-11-08T13:34:15.789Z" ID="SAMLY2lib_msg_e22ca2eb2cd0014ac9c34617b52b836eebb6141762df2bcf" Version="2.0" InResponseTo="_cdeb6c41e0e34221ccba36ec18db2d84" xmlns:urn="urn:oasis:names:tc:SAML:2.0:protocol"><urn1:Issuer Format="" xmlns:urn1="urn:oasis:names:tc:SAML:2.0:assertion">https://unity.eudat-aai.fz-juelich.de:8443/saml-
idp/metadata</urn1:Issuer><urn:Status><urn:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Requester"/><urn:StatusMessage>Logged out entity name must be present in SLO request and only NameID is supported</urn:StatusMessage></urn:Status></urn:LogoutResponse>
2019-11-08T14:34:15,790 [qtp1417465-7314] TRACE unity.server.saml.ResponseHandlerBase: Returned Redirect URL is:
https://test.ggus.eu/Shibboleth.sso/SLO/Redirect?SAMLResponse=fZJbaxsxEEb%2FyqD3vUi7Wa%2BFbSgNBYPTQhwC7YvRZexs2ZW2Ggma%2FvrKbgPbPuRNGkZnzsdok4KTB3%2FxKT4izd4Rwp4o4d5RVC5umaj5uuC8qPsn3simlfyuXPXrbwz291t2%2FPBw%2BCrGQZ8mupxQCKMEamFsXfNWmbVp2o6v9J3QfdMhat3xlq86Yc9CmzODZww0eJfHlHUmujeJJ79lJ2NRd6blWGPTCsGN0SpTDO%2BtFrZvGfycRkcyZ9iyaxCvaCDp1IQko5FXOZnBcg4%2BeuNHttvk
Ni5vCQN88mFSOeKCw98HKSIMMQuz3UuMM8mqSm6IryUmq2Kh1FCefxXfE46DeSktyr5tm4rUNBaDnasJo8p9alMtNG5O8hhVTLQ8f%2FQW4VmNCd93olu3fMQfCSliYNWS8oBE6oK7vOMLWsh7BnQxK8OVBFOiCBphDki5DoOD4%2BELhD8wUC4%2FceMrfM7N%2B3sYCCjNsw8R7S3Ef1OWtb%2BXfz%2FX7jc%3D
Cheers,
Shiraz
On Fri, Nov 8, 2019 at 9:44 AM Krzysztof Benedyczak <kb...@un...<mailto:kb...@un...>> wrote:
Hi Shiraz,
W dniu 06.11.2019 o 13:00, Shiraz Memon pisze:
Hi Krzysztof,
I have configured an SP, which is based on shibboleth. I can successfully sign-in but unfortunately I cannot log-out (SLO). Below are the SLO request and response messages from sp and unity respectively, and also the SP configuration in unity.
<?xml version="1.0" encoding="UTF-8"?>
<samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://unity.eudat-aai.fz-juelich.de/saml-idp/SLO-WEB" ID="_56f68d31d948b0ccc241c0efe0697d36" IssueInstant="2019-11-06T11:17:58Z" Version="2.0"> <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://test.ggus.eu/EOSC-hub/secure</saml:Issuer> <samlp:Extensions> <aslo:Asynchronous xmlns:aslo="urn:oasis:names:tc:SAML:2.0:protocol:ext:async-slo" /> </samlp:Extensions> <saml:EncryptedID xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"> <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Type="http://www.w3.org/2001/04/xmlenc#Element"> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" /> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <xenc:EncryptedKey> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p" /> <xenc:CipherData> <xenc:CipherValue>S/GMplTHJ2N0vbOVMhyUK8bBTNriupFbp12wwnvUmioEjx5xpBhYGYgEF5IQChVm66GdgIJ8czAk RX1HbwqOGUktGocmR+Fcxq9wn5OSrQ4i/mj4kIF+aqlh8+bir2gua5XLd16DPn61CM3bUv2HWfNK P0IAO3D77ezdJ+DR4jZ5wEfqZE3+OFplfMyzc2s7w4iswSs/cs/3fXJzkSFKGUP32P50izi4HxBg eN7F7knsFHiD8P0b62btMOUQCHHG6LG9U7Esfjwe+uO88wJEmge295FQWRwJHvrbO8O7rEwnDu8+ 1d1/Vnb0OT5lvM0E8sC/LYUKpO62DHjUvVI60BQ2/6NJPVsTjV4CEp77nQK7aR6dmJaVxlFJ2EZw cD3s49RPazXpATvAPLrg/0t2lLFIB/Z5g8AX+5FqBn1vkqrYpKQoBdnTjO/j5LGYbs8q9s2/HlP9 4Mf9iCW9YOCV1Q8KOLAvgLHJWKCVHNQQARTIHHN2ocX2jNWiWf0zaG/1sEW8KP6uOyoLpnTQ9YB6 I81yndVV+YXVWQYLk7wrUB2KPXVHCEshjmHzwJxhvWvIQYrvpBuLOLfAjShNpFsHyn/yCBBs5LdE RlDAdcKkikAQO5MkJjcLSkY0Jh3C5PAJ+jPhjZ5Lv9z1+VuJabb9lpLCNAI8Lx0dYJ7LbExv8Gw=</xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedKey> </ds:KeyInfo> <xenc:CipherData> <xenc:CipherValue>uwTdWX75kV+KaSwdLSY0miFxW7oaIEqIpUF9LTZgYEsgHzh6lQeJs0trR9CzTF6+b8/+j8mpCCkF 6BsHJcikJRZySAo2THBfZlTk1FIcOXgOMW6U2k3loUSxr6JT1mXFXXCBkUeraP38JJ62Yg9GMGFd DYKNtbTI2fuK6Z8TwBwK/lDeJ+atIOcnTT8AKBYXpo0Ni/s+0XivyecXPKdkYIRSh34u9nZ2DVr0 ENrgpmXR1X+hctYU7NeRgEFjQjCf</xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData> </saml:EncryptedID> <samlp:SessionIndex>SAMLY2lib_assert_fd9a89a3fa593431e7c87fc61266a55d5b3b64d8ea7f6bc3</samlp:SessionIndex> </samlp:LogoutRequest>
<?xml version="1.0" encoding="UTF-8"?> <urn:LogoutResponse xmlns:urn="urn:oasis:names:tc:SAML:2.0:protocol" IssueInstant="2019-11-06T11:33:04.725Z" ID="SAMLY2lib_msg_64b9f960635a040fc79f7707675d67b026020087543ab8f8" Version="2.0" InResponseTo="_4d31d3d8048d719329c6c5f43c35fb39"> <urn1:Issuer xmlns:urn1="urn:oasis:names:tc:SAML:2.0:assertion" Format="">https://unity.eudat-aai.fz-juelich.de:8443/saml-idp/metadata</urn1:Issuer> <urn:Status> <urn:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Requester" /> <urn:StatusMessage>Logged out entity name must be present in SLO request and only NameID is supported</urn:StatusMessage> </urn:Status> </urn:LogoutResponse>
Looks like some incompatibility on what is sent to Unity in logout request, as a subject to be logged out. I can't say more as the request is encrypted.
If you enable trace logging you should be able to see decrypted message in log, then we can say more. Looks like the subject (i.e. the one to be logged out) is provided in some of unsupported ways to unity. I suppose this was not working with older unity version too, right? And even if it was most likely the triggering is on the client side.
Best,
Krzysztof
--
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 Volker Rieke
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
|
|
From: Krzysztof B. <kb...@un...> - 2019-11-08 08:45:09
|
Hi Shiraz, W dniu 06.11.2019 o 13:00, Shiraz Memon pisze: > Hi Krzysztof, > > I have configured an SP, which is based on shibboleth. I can > successfully sign-in but unfortunately I cannot log-out (SLO). Below > are the SLO request and response messages from sp and unity > respectively, and also the SP configuration in unity. > <?xml version="1.0"encoding="UTF-8"?> > <samlp:LogoutRequest > xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" > Destination="https://unity.eudat-aai.fz-juelich.de/saml-idp/SLO-WEB" > ID="_56f68d31d948b0ccc241c0efe0697d36" > IssueInstant="2019-11-06T11:17:58Z" Version="2.0"><saml:Issuer > xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://test.ggus.eu/EOSC-hub/secure</saml:Issuer><samlp:Extensions><aslo:Asynchronous > xmlns:aslo="urn:oasis:names:tc:SAML:2.0:protocol:ext:async-slo" > /></samlp:Extensions><saml:EncryptedID > xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"><xenc:EncryptedData > xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" > Type="http://www.w3.org/2001/04/xmlenc#Element"><xenc:EncryptionMethod > Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" /><ds:KeyInfo > xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><xenc:EncryptedKey><xenc:EncryptionMethod > Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p" > /><xenc:CipherData><xenc:CipherValue>S/GMplTHJ2N0vbOVMhyUK8bBTNriupFbp12wwnvUmioEjx5xpBhYGYgEF5IQChVm66GdgIJ8czAk > RX1HbwqOGUktGocmR+Fcxq9wn5OSrQ4i/mj4kIF+aqlh8+bir2gua5XLd16DPn61CM3bUv2HWfNK > P0IAO3D77ezdJ+DR4jZ5wEfqZE3+OFplfMyzc2s7w4iswSs/cs/3fXJzkSFKGUP32P50izi4HxBg > eN7F7knsFHiD8P0b62btMOUQCHHG6LG9U7Esfjwe+uO88wJEmge295FQWRwJHvrbO8O7rEwnDu8+ > 1d1/Vnb0OT5lvM0E8sC/LYUKpO62DHjUvVI60BQ2/6NJPVsTjV4CEp77nQK7aR6dmJaVxlFJ2EZw > cD3s49RPazXpATvAPLrg/0t2lLFIB/Z5g8AX+5FqBn1vkqrYpKQoBdnTjO/j5LGYbs8q9s2/HlP9 > 4Mf9iCW9YOCV1Q8KOLAvgLHJWKCVHNQQARTIHHN2ocX2jNWiWf0zaG/1sEW8KP6uOyoLpnTQ9YB6 > I81yndVV+YXVWQYLk7wrUB2KPXVHCEshjmHzwJxhvWvIQYrvpBuLOLfAjShNpFsHyn/yCBBs5LdE > RlDAdcKkikAQO5MkJjcLSkY0Jh3C5PAJ+jPhjZ5Lv9z1+VuJabb9lpLCNAI8Lx0dYJ7LbExv8Gw=</xenc:CipherValue></xenc:CipherData></xenc:EncryptedKey></ds:KeyInfo><xenc:CipherData><xenc:CipherValue>uwTdWX75kV+KaSwdLSY0miFxW7oaIEqIpUF9LTZgYEsgHzh6lQeJs0trR9CzTF6+b8/+j8mpCCkF > 6BsHJcikJRZySAo2THBfZlTk1FIcOXgOMW6U2k3loUSxr6JT1mXFXXCBkUeraP38JJ62Yg9GMGFd > DYKNtbTI2fuK6Z8TwBwK/lDeJ+atIOcnTT8AKBYXpo0Ni/s+0XivyecXPKdkYIRSh34u9nZ2DVr0 > ENrgpmXR1X+hctYU7NeRgEFjQjCf</xenc:CipherValue></xenc:CipherData></xenc:EncryptedData></saml:EncryptedID><samlp:SessionIndex>SAMLY2lib_assert_fd9a89a3fa593431e7c87fc61266a55d5b3b64d8ea7f6bc3</samlp:SessionIndex></samlp:LogoutRequest> > > <?xml version="1.0" encoding="UTF-8"?><urn:LogoutResponse > xmlns:urn="urn:oasis:names:tc:SAML:2.0:protocol" > IssueInstant="2019-11-06T11:33:04.725Z" > ID="SAMLY2lib_msg_64b9f960635a040fc79f7707675d67b026020087543ab8f8" > Version="2.0" > InResponseTo="_4d31d3d8048d719329c6c5f43c35fb39"><urn1:Issuer > xmlns:urn1="urn:oasis:names:tc:SAML:2.0:assertion" > Format="">https://unity.eudat-aai.fz-juelich.de:8443/saml-idp/metadata</urn1:Issuer><urn:Status><urn:StatusCode > Value="urn:oasis:names:tc:SAML:2.0:status:Requester" > /><urn:StatusMessage>Logged out entity name must be present in SLO > request and only NameID is > supported</urn:StatusMessage></urn:Status></urn:LogoutResponse> > Looks like some incompatibility on what is sent to Unity in logout request, as a subject to be logged out. I can't say more as the request is encrypted. If you enable trace logging you should be able to see decrypted message in log, then we can say more. Looks like the subject (i.e. the one to be logged out) is provided in some of unsupported ways to unity. I suppose this was not working with older unity version too, right? And even if it was most likely the triggering is on the client side. Best, Krzysztof |
|
From: Shiraz M. <a....@fz...> - 2019-11-06 12:02:20
|
Hi Krzysztof, I have configured an SP, which is based on shibboleth. I can successfully sign-in but unfortunately I cannot log-out (SLO). Below are the SLO request and response messages from sp and unity respectively, and also the SP configuration in unity. <?xml version="1.0" encoding="UTF-8"?> <samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://unity.eudat-aai.fz-juelich.de/saml-idp/SLO-WEB" ID="_56f68d31d948b0ccc241c0efe0697d36" IssueInstant="2019-11-06T11:17:58Z" Version="2.0"> <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://test.ggus.eu/EOSC-hub/secure</saml:Issuer> <samlp:Extensions> <aslo:Asynchronous xmlns:aslo="urn:oasis:names:tc:SAML:2.0:protocol:ext:async-slo" /> </samlp:Extensions> <saml:EncryptedID xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"> <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Type="http://www.w3.org/2001/04/xmlenc#Element"> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" /> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <xenc:EncryptedKey> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p" /> <xenc:CipherData> <xenc:CipherValue>S/GMplTHJ2N0vbOVMhyUK8bBTNriupFbp12wwnvUmioEjx5xpBhYGYgEF5IQChVm66GdgIJ8czAk RX1HbwqOGUktGocmR+Fcxq9wn5OSrQ4i/mj4kIF+aqlh8+bir2gua5XLd16DPn61CM3bUv2HWfNK P0IAO3D77ezdJ+DR4jZ5wEfqZE3+OFplfMyzc2s7w4iswSs/cs/3fXJzkSFKGUP32P50izi4HxBg eN7F7knsFHiD8P0b62btMOUQCHHG6LG9U7Esfjwe+uO88wJEmge295FQWRwJHvrbO8O7rEwnDu8+ 1d1/Vnb0OT5lvM0E8sC/LYUKpO62DHjUvVI60BQ2/6NJPVsTjV4CEp77nQK7aR6dmJaVxlFJ2EZw cD3s49RPazXpATvAPLrg/0t2lLFIB/Z5g8AX+5FqBn1vkqrYpKQoBdnTjO/j5LGYbs8q9s2/HlP9 4Mf9iCW9YOCV1Q8KOLAvgLHJWKCVHNQQARTIHHN2ocX2jNWiWf0zaG/1sEW8KP6uOyoLpnTQ9YB6 I81yndVV+YXVWQYLk7wrUB2KPXVHCEshjmHzwJxhvWvIQYrvpBuLOLfAjShNpFsHyn/yCBBs5LdE RlDAdcKkikAQO5MkJjcLSkY0Jh3C5PAJ+jPhjZ5Lv9z1+VuJabb9lpLCNAI8Lx0dYJ7LbExv8Gw=</xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedKey> </ds:KeyInfo> <xenc:CipherData> <xenc:CipherValue>uwTdWX75kV+KaSwdLSY0miFxW7oaIEqIpUF9LTZgYEsgHzh6lQeJs0trR9CzTF6+b8/+j8mpCCkF 6BsHJcikJRZySAo2THBfZlTk1FIcOXgOMW6U2k3loUSxr6JT1mXFXXCBkUeraP38JJ62Yg9GMGFd DYKNtbTI2fuK6Z8TwBwK/lDeJ+atIOcnTT8AKBYXpo0Ni/s+0XivyecXPKdkYIRSh34u9nZ2DVr0 ENrgpmXR1X+hctYU7NeRgEFjQjCf</xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData> </saml:EncryptedID> <samlp:SessionIndex>SAMLY2lib_assert_fd9a89a3fa593431e7c87fc61266a55d5b3b64d8ea7f6bc3</samlp:SessionIndex> </samlp:LogoutRequest> <?xml version="1.0" encoding="UTF-8"?> <urn:LogoutResponse xmlns:urn="urn:oasis:names:tc:SAML:2.0:protocol" IssueInstant="2019-11-06T11:33:04.725Z" ID="SAMLY2lib_msg_64b9f960635a040fc79f7707675d67b026020087543ab8f8" Version="2.0" InResponseTo="_4d31d3d8048d719329c6c5f43c35fb39"> <urn1:Issuer xmlns:urn1="urn:oasis:names:tc:SAML:2.0:assertion" Format="">https://unity.eudat-aai.fz-juelich.de:8443/saml-idp/metadata</urn1:Issuer> <urn:Status> <urn:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Requester" /> <urn:StatusMessage>Logged out entity name must be present in SLO request and only NameID is supported</urn:StatusMessage> </urn:Status> </urn:LogoutResponse> Unity configuration: unity.saml.acceptedSP.13.entity=https://test.ggus.eu/EOSC-hub/secure unity.saml.acceptedSP.13.returnURL=https://test.ggus.eu/Shibboleth.sso/SAML2/POST unity.saml.acceptedSP.13.certificate=GGUS unity.saml.acceptedSP.13.redirectLogoutEndpoint=https://test.ggus.eu/Shibboleth.sso/SLO/Redirect Thanks, Shiraz -- 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 Volker Rieke Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ |
