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
(2) |
Sep
(8) |
Oct
(12) |
Nov
|
Dec
|
From: Sander A. <sa....@fz...> - 2025-10-14 07:08:34
|
Good morning Krzysztof, at the moment we have the problem, that usage of refresh tokens fails due to missing ACR information. Our idea was to send the information from the original authN. If you feel more comftable with removing them from the token, it is also fine. If the RP would need ACR information, it would need to do a step-up authentication after using a RF token. Best regards, Sander On Fri, 2025-10-10 at 14:14 +0200, Krzysztof Benedyczak wrote: > > Hi Sander, > > > > > W dniu 6.10.2025 o 13:58, Sander Apweiler pisze: > > > > > > Hi Krzysztof, > > hi Roman, > > > > we encountered an issues where a public OAuth client gets error, > > when > > it tries to get a new access and refresh token, using a refresh > > token. > > The output translation profile creates an error because it can not > > access upstreamACRs. Which might make sense, since in using refresh > > tokens you do not have an upstream ACR. Would it make more sense to > > store the information from the original login and send the result > > instead of trying to resolve it again? > > > > I assume the same issue comes up for confidential clients. > > > > > > You are right: upstreamACR and several other variables in the output > profile are not accessible during token refresh. > > I'd like to understand your question better. Do you suggest the > output profile provides information from the original authN (which > happened during initial access token creation)? > > Or rather to expose information from the refreshed token? Or just > that this is token refresh? > > Thank you, > Krzysztof > > _______________________________________________ > Unity-idm-discuss mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss -- Large-Scale Data Science Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Dr. Stephanie Bauer (stellvertretende Vorsitzende), Prof. Dr. Ir. Pieter Jansens, Prof. Dr. Laurens Kuipers ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
From: Sander A. <sa....@fz...> - 2025-10-14 06:59:02
|
Good morning, please find attached the stack trace. The current Java version is: openjdk 21.0.8 2025-07-15 OpenJDK Runtime Environment (build 21.0.8+9-Ubuntu-0ubuntu122.04.1) OpenJDK 64-Bit Server VM (build 21.0.8+9-Ubuntu-0ubuntu122.04.1, mixed mode, sharing) Best regards, Sander On Fri, 2025-10-10 at 14:43 +0200, Krzysztof Benedyczak wrote: > > W dniu 10.10.2025 o 14:37, Bernd Schuller pisze: > > > > hi, > > > > ... just a thought, while the algorithm itself is supported in > > JOSE since a long time, maybe there is some bug going on. > > > > There are two keys under > > https://proxy.acc.myaccessid.org/OIDC/jwks > > one is RSA, the other EC. Maybe the introspection algorithm check > > uses the RSA key and complains about the ES algo? > > > > > > > Hmm, maybe... but the error message is not suggesting that. @Sander, > is there a stack trace in you log? > > Krzysztof > > _______________________________________________ > Unity-idm-discuss mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss -- Large-Scale Data Science Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Dr. Stephanie Bauer (stellvertretende Vorsitzende), Prof. Dr. Ir. Pieter Jansens, Prof. Dr. Laurens Kuipers ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
From: Krzysztof B. <kb...@un...> - 2025-10-13 16:22:38
|
Hi Laura, W dniu 10.10.2025 o 16:16, Laura Hofer pisze: > Hi Krzysztof, > > thank you for the quick reply. Having multiple forms would be very > helpful. > > The policy document is embedded and acceptance is not optional. > > The update enquiry form was created using the wizard, the type is > sticky and the target groups are the group itself and the root group. > For the policy agreement, we selected the relevant policy document, > checkbox not selected. The text is the title of the policy. > > With the same configuration, the policy is displayed on other > instances in the form on the home endpoint with a checkbox, and if > this is not selected and you try to submit, an error message appears. > > Let us know if we can provide any further infos. > Can you please, check one thing *for the user on which you are experiencing the problem*: in admin console -> Directory Browser find that user in the Root group; then inspect the attributes. Is there an attribute "sys:policy-agreement-state"? If yes - what is the value? Also: * are there any other elements in the enquiry and are those shown all right? * I'm assuming you have not modified any advanced options like "Enquiry target groups" or "Target condition" and the user on which the problem is experienced is a member of the target group (here: UpMan project)? Cheers, Krzysztof > Kind regards and have a nice weekend, > Laura > > Am 10.10.25 um 14:18 schrieb Krzysztof Benedyczak: >> Hi Laura, >> >> W dniu 10.10.2025 o 11:58, Laura Hofer pisze: >>> Hi Roman, Hi Krzysztof, >>> >>> We need some help with the Enquiry Update Form. Firstly, we have the >>> problem that we cannot display more than one in the home endpoint. >>> Secondly, and this is a problem we only have on our production >>> instance, so perhaps you know more about it, the non-optional policy >>> agreements are not displayed when viewing the home endpoint. We >>> don't have this problem on other instances. Can you think of any >>> reason why this problem might be occurring? Or would you perhaps >>> know which loggers we would need to increase, as we are not >>> currently seeing any major error messages? >>> >> Yes - user home is limited to a single form. I think in Unity 4 we >> can quite easily support more if this is the main problem. >> >> For the issue with agreements: can you please share more details of >> your setup? I.e how form is setup and as well the setup of agreement >> doc. >> >> >> Thanks, >> Krzysztof >> >> |
From: Laura H. <l....@fz...> - 2025-10-10 14:16:21
|
Hi Krzysztof, thank you for the quick reply. Having multiple forms would be very helpful. The policy document is embedded and acceptance is not optional. The update enquiry form was created using the wizard, the type is sticky and the target groups are the group itself and the root group. For the policy agreement, we selected the relevant policy document, checkbox not selected. The text is the title of the policy. With the same configuration, the policy is displayed on other instances in the form on the home endpoint with a checkbox, and if this is not selected and you try to submit, an error message appears. Let us know if we can provide any further infos. Kind regards and have a nice weekend, Laura Am 10.10.25 um 14:18 schrieb Krzysztof Benedyczak: > Hi Laura, > > W dniu 10.10.2025 o 11:58, Laura Hofer pisze: >> Hi Roman, Hi Krzysztof, >> >> We need some help with the Enquiry Update Form. Firstly, we have the >> problem that we cannot display more than one in the home endpoint. >> Secondly, and this is a problem we only have on our production >> instance, so perhaps you know more about it, the non-optional policy >> agreements are not displayed when viewing the home endpoint. We don't >> have this problem on other instances. Can you think of any reason why >> this problem might be occurring? Or would you perhaps know which >> loggers we would need to increase, as we are not currently seeing any >> major error messages? >> > Yes - user home is limited to a single form. I think in Unity 4 we can > quite easily support more if this is the main problem. > > For the issue with agreements: can you please share more details of > your setup? I.e how form is setup and as well the setup of agreement doc. > > > Thanks, > Krzysztof > > -- "Das Forschungszentrum Jülich stellt zurzeit auf einen neuen Zertifikatsanbieter zum digitalen Signieren von E-Mails um. Während dieser Umstellungsarbeiten kann es vorkommen, dass das DFN Community PKI Zertifikat, mit dem diese E-Mail signiert worden ist, als ungültig angezeigt wird." Large-Scale Data Science Juelich Supercomputing Centre phone: +49 2461 61 6576 fax: +49 2461 61 6656 email: l....@fz... --------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Dr. Stephanie Bauer (stellvertretende Vorsitzende), Prof. Dr. Ir. Pieter Jansens, Prof. Dr. Laurens Kuipers --------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------- |
From: Krzysztof B. <kb...@un...> - 2025-10-10 12:43:30
|
W dniu 10.10.2025 o 14:37, Bernd Schuller pisze: > hi, > > ... just a thought, while the algorithm itself is supported in JOSE > since a long time, maybe there is some bug going on. > > There are two keys under https://proxy.acc.myaccessid.org/OIDC/jwks > one is RSA, the other EC. Maybe the introspection algorithm check uses > the RSA key and complains about the ES algo? Hmm, maybe... but the error message is not suggesting that. @Sander, is there a stack trace in you log? Krzysztof |
From: Bernd S. <b.s...@fz...> - 2025-10-10 12:37:26
|
hi, ... just a thought, while the algorithm itself is supported in JOSE since a long time, maybe there is some bug going on. There are two keys under https://proxy.acc.myaccessid.org/OIDC/jwks one is RSA, the other EC. Maybe the introspection algorithm check uses the RSA key and complains about the ES algo? Best regards, Bernd On 10/10/25 14:31, Krzysztof Benedyczak wrote: > W dniu 10.10.2025 o 14:07, Sander Apweiler pisze: >> Dear Krzysztof, >> dear Roman, >> >> We are working on integration with EOSC and configuring the token >> introspection for this. It seems that EOSC AAI uses an algorithm, which >> is not supportet by unity: >> >> 2025-10-07T12:16:56,494 [qtp1797879583-58] DEBUG unity.server.oauth.RemoteTokenIntrospectionService: Remote token introspection, token ...1cda2b >> 2025-10-07T12:16:56,495 [qtp1797879583-58] DEBUG unity.server.oauth.OAuthDiscoveryMetadataCache: Get fresh oauth OIDC metadata fromhttps://proxy.acc.myaccessid.org/.well-known/openid-configuration >> 2025-10-07T12:16:56,495 [qtp1797879583-58] DEBUG unity.server.oauth.OpenIdConnectDiscovery: Download metadata fromhttps://proxy.acc.myaccessid.org/.well-known/openid-configuration >> 2025-10-07T12:16:56,674 [qtp1797879583-58] DEBUG unity.server.oauth.OAuthJWKSetCache: Get fresh JWKSet fromhttps://proxy.acc.myaccessid.org/OIDC/jwks >> 2025-10-07T12:16:56,675 [qtp1797879583-58] DEBUG unity.server.oauth.KeyResource: Download JWKSet fromhttps://proxy.acc.myaccessid.org/OIDC/jwks >> 2025-10-07T12:16:56,752 [qtp1797879583-58] ERROR unity.server.oauth.RemoteTokenIntrospectionService: Invalid sign of token ...1cda2b >> com.nimbusds.jose.JOSEException: Unsupported JWS algorithm ES256, must be RS256, RS384, RS512, PS256, PS384 or PS512 >> >> Is there a possibility to support ES256 as well or requires this code >> changes? > > > This is strange - this algorithm should be supported since long time. > Can you please provide which version of Unity you are using and which JDK? > > Also - is there an option to get some token for verification (can be > expired)? > > Thanks, > Krzysztof > > > > _______________________________________________ > Unity-idm-discuss mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss -- Dr. Bernd Schuller Large Scale Data Science, Juelich Supercomputing Centre https://www.fz-juelich.de/ias/jsc Phone: +49 246161-8736 |
From: Krzysztof B. <kb...@un...> - 2025-10-10 12:31:53
|
W dniu 10.10.2025 o 14:07, Sander Apweiler pisze: > Dear Krzysztof, > dear Roman, > > We are working on integration with EOSC and configuring the token > introspection for this. It seems that EOSC AAI uses an algorithm, which > is not supportet by unity: > > 2025-10-07T12:16:56,494 [qtp1797879583-58] DEBUG unity.server.oauth.RemoteTokenIntrospectionService: Remote token introspection, token ...1cda2b > 2025-10-07T12:16:56,495 [qtp1797879583-58] DEBUG unity.server.oauth.OAuthDiscoveryMetadataCache: Get fresh oauth OIDC metadata fromhttps://proxy.acc.myaccessid.org/.well-known/openid-configuration > 2025-10-07T12:16:56,495 [qtp1797879583-58] DEBUG unity.server.oauth.OpenIdConnectDiscovery: Download metadata fromhttps://proxy.acc.myaccessid.org/.well-known/openid-configuration > 2025-10-07T12:16:56,674 [qtp1797879583-58] DEBUG unity.server.oauth.OAuthJWKSetCache: Get fresh JWKSet fromhttps://proxy.acc.myaccessid.org/OIDC/jwks > 2025-10-07T12:16:56,675 [qtp1797879583-58] DEBUG unity.server.oauth.KeyResource: Download JWKSet fromhttps://proxy.acc.myaccessid.org/OIDC/jwks > 2025-10-07T12:16:56,752 [qtp1797879583-58] ERROR unity.server.oauth.RemoteTokenIntrospectionService: Invalid sign of token ...1cda2b > com.nimbusds.jose.JOSEException: Unsupported JWS algorithm ES256, must be RS256, RS384, RS512, PS256, PS384 or PS512 > > Is there a possibility to support ES256 as well or requires this code > changes? This is strange - this algorithm should be supported since long time. Can you please provide which version of Unity you are using and which JDK? Also - is there an option to get some token for verification (can be expired)? Thanks, Krzysztof |
From: Krzysztof B. <kb...@un...> - 2025-10-10 12:18:25
|
Hi Laura, W dniu 10.10.2025 o 11:58, Laura Hofer pisze: > Hi Roman, Hi Krzysztof, > > We need some help with the Enquiry Update Form. Firstly, we have the > problem that we cannot display more than one in the home endpoint. > Secondly, and this is a problem we only have on our production > instance, so perhaps you know more about it, the non-optional policy > agreements are not displayed when viewing the home endpoint. We don't > have this problem on other instances. Can you think of any reason why > this problem might be occurring? Or would you perhaps know which > loggers we would need to increase, as we are not currently seeing any > major error messages? > Yes - user home is limited to a single form. I think in Unity 4 we can quite easily support more if this is the main problem. For the issue with agreements: can you please share more details of your setup? I.e how form is setup and as well the setup of agreement doc. Thanks, Krzysztof |
From: Krzysztof B. <kb...@un...> - 2025-10-10 12:14:50
|
Hi Sander, W dniu 6.10.2025 o 13:58, Sander Apweiler pisze: > Hi Krzysztof, > hi Roman, > > we encountered an issues where a public OAuth client gets error, when > it tries to get a new access and refresh token, using a refresh token. > The output translation profile creates an error because it can not > access upstreamACRs. Which might make sense, since in using refresh > tokens you do not have an upstream ACR. Would it make more sense to > store the information from the original login and send the result > instead of trying to resolve it again? > > I assume the same issue comes up for confidential clients. > You are right: upstreamACR and several other variables in the output profile are not accessible during token refresh. I'd like to understand your question better. Do you suggest the output profile provides information from the original authN (which happened during initial access token creation)? Or rather to expose information from the refreshed token? Or just that this is token refresh? Thank you, Krzysztof |
From: Sander A. <sa....@fz...> - 2025-10-10 12:07:47
|
Dear Krzysztof, dear Roman, We are working on integration with EOSC and configuring the token introspection for this. It seems that EOSC AAI uses an algorithm, which is not supportet by unity: 2025-10-07T12:16:56,494 [qtp1797879583-58] DEBUG unity.server.oauth.RemoteTokenIntrospectionService: Remote token introspection, token ...1cda2b 2025-10-07T12:16:56,495 [qtp1797879583-58] DEBUG unity.server.oauth.OAuthDiscoveryMetadataCache: Get fresh oauth OIDC metadata from https://proxy.acc.myaccessid.org/.well-known/openid-configuration 2025-10-07T12:16:56,495 [qtp1797879583-58] DEBUG unity.server.oauth.OpenIdConnectDiscovery: Download metadata from https://proxy.acc.myaccessid.org/.well-known/openid-configuration 2025-10-07T12:16:56,674 [qtp1797879583-58] DEBUG unity.server.oauth.OAuthJWKSetCache: Get fresh JWKSet from https://proxy.acc.myaccessid.org/OIDC/jwks 2025-10-07T12:16:56,675 [qtp1797879583-58] DEBUG unity.server.oauth.KeyResource: Download JWKSet from https://proxy.acc.myaccessid.org/OIDC/jwks 2025-10-07T12:16:56,752 [qtp1797879583-58] ERROR unity.server.oauth.RemoteTokenIntrospectionService: Invalid sign of token ...1cda2b com.nimbusds.jose.JOSEException: Unsupported JWS algorithm ES256, must be RS256, RS384, RS512, PS256, PS384 or PS512 Is there a possibility to support ES256 as well or requires this code changes? Best regards, Sander -- Large-Scale Data Science Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Dr. Stephanie Bauer (stellvertretende Vorsitzende), Prof. Dr. Ir. Pieter Jansens, Prof. Dr. Laurens Kuipers ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
From: Laura H. <l....@fz...> - 2025-10-10 09:58:34
|
Hi Roman, Hi Krzysztof, We need some help with the Enquiry Update Form. Firstly, we have the problem that we cannot display more than one in the home endpoint. Secondly, and this is a problem we only have on our production instance, so perhaps you know more about it, the non-optional policy agreements are not displayed when viewing the home endpoint. We don't have this problem on other instances. Can you think of any reason why this problem might be occurring? Or would you perhaps know which loggers we would need to increase, as we are not currently seeing any major error messages? Kind regards, Laura -- "Das Forschungszentrum Jülich stellt zurzeit auf einen neuen Zertifikatsanbieter zum digitalen Signieren von E-Mails um. Während dieser Umstellungsarbeiten kann es vorkommen, dass das DFN Community PKI Zertifikat, mit dem diese E-Mail signiert worden ist, als ungültig angezeigt wird." Large-Scale Data Science Juelich Supercomputing Centre phone: +49 2461 61 6576 fax: +49 2461 61 6656 email: l....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschaeftsfuehrung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Karsten Beneke (stellv. Vorsitzender), Dr. Ir. Pieter Jansens ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
From: Sander A. <sa....@fz...> - 2025-10-06 11:59:00
|
Hi Krzysztof, hi Roman, we encountered an issues where a public OAuth client gets error, when it tries to get a new access and refresh token, using a refresh token. The output translation profile creates an error because it can not access upstreamACRs. Which might make sense, since in using refresh tokens you do not have an upstream ACR. Would it make more sense to store the information from the original login and send the result instead of trying to resolve it again? I assume the same issue comes up for confidential clients. I also attached the stack trace itself. Best regards, Sander -- Large-Scale Data Science Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Dr. Stephanie Bauer (stellvertretende Vorsitzende), Prof. Dr. Ir. Pieter Jansens, Prof. Dr. Laurens Kuipers ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
From: Sander A. <sa....@fz...> - 2025-09-22 06:24:34
|
Hi Andre, thank you very much for the information/link. Best regards, Sander On Thu, 2025-09-18 at 14:09 +0200, André Moreira via Unity-idm-discuss wrote: > Hi Sander, > > We do that by concatenating: "_entryFromMetadata_" + > DigestUtils.md5Hex(samlEntityId) > Follow the code from here: > https://github.com/unity-idm/unity/blob/master/saml/src/main/java/pl/edu/icm/unity/saml/sp/config/TrustedIdPKey.java#L26 > > The ID can also be found by selecting the IdP on Unity login screen > and > then looking at the generated cookie for Unity URL. > > > Regards, > André Moreira > > On 18/09/2025 12:08, Sander Apweiler wrote: > > Hi Krystof, > > hi Roman, > > > > is there any update on the easier identification of SAML IdPs in > > preselected authentication? According to this ticket [1], I don't > > see > > any progress. Can you also remember me how to find this ID of the > > IdP. > > > > Best regards, > > Sander > > > > [1]: https://unity-idm.atlassian.net/browse/UY-1007 > > > > > > > > _______________________________________________ > > Unity-idm-discuss mailing list > > Uni...@li... > > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss > > -- > André Moreira > CLARIN ERIC > https://www.clarin.eu > -- Large-Scale Data Science Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Dr. Stephanie Bauer (stellvertretende Vorsitzende), Prof. Dr. Ir. Pieter Jansens, Prof. Dr. Laurens Kuipers ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
From: André M. <an...@cl...> - 2025-09-18 12:26:19
|
Hi Sander, We do that by concatenating: "_entryFromMetadata_" + DigestUtils.md5Hex(samlEntityId) Follow the code from here: https://github.com/unity-idm/unity/blob/master/saml/src/main/java/pl/edu/icm/unity/saml/sp/config/TrustedIdPKey.java#L26 The ID can also be found by selecting the IdP on Unity login screen and then looking at the generated cookie for Unity URL. Regards, André Moreira On 18/09/2025 12:08, Sander Apweiler wrote: > Hi Krystof, > hi Roman, > > is there any update on the easier identification of SAML IdPs in > preselected authentication? According to this ticket [1], I don't see > any progress. Can you also remember me how to find this ID of the IdP. > > Best regards, > Sander > > [1]: https://unity-idm.atlassian.net/browse/UY-1007 > > > > _______________________________________________ > Unity-idm-discuss mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss -- André Moreira CLARIN ERIC https://www.clarin.eu |
From: Sander A. <sa....@fz...> - 2025-09-18 10:08:53
|
Hi Krystof, hi Roman, is there any update on the easier identification of SAML IdPs in preselected authentication? According to this ticket [1], I don't see any progress. Can you also remember me how to find this ID of the IdP. Best regards, Sander [1]: https://unity-idm.atlassian.net/browse/UY-1007 -- Large-Scale Data Science Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Dr. Stephanie Bauer (stellvertretende Vorsitzende), Prof. Dr. Ir. Pieter Jansens, Prof. Dr. Laurens Kuipers ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
From: Krzysztof B. <kb...@un...> - 2025-09-17 11:20:18
|
Hi Laura, W dniu 17.09.2025 o 11:09, Laura Hofer pisze: > Hi Krzysztof, Hi Roman, > > we are currently planning to switch our Unity setup to an HA setup > with one master and two workers. > This raised the question of how best to proceed with Unity updates: Do > all Unity instances have to be stopped and updated at the same time, > or can the instances be updated gradually (e.g. within a few hours)? > Could the second option cause problems with the database if, for > example, the master is already running a newer version of Unity, but > the workers are still running an older version? Newer Unity can not work on older DB - actually at the startup it will try to update DB schema. That said, if you want to have close-to-zero downtime deployment blue-green sounds as the proper approach. 0. Blue is running old version (and can have HA, e.g. 3 instance) 1. install the new version on Green 2. (critical; see notes below) stop Blue, clone DB from Blue to Green 3. start the stack on Green 4. switch routing to Green 5. deprovision Blue In this scheme #2 is critical, this is when your downtime starts (ends at #4). Typically such short downtime is OK: that should take few minutes, and in case of troubles with new installation rollback is immediate - you just start Blue again. But we can do better here: instead of fully stopping Unity, we can have a feature to put it into RO mode. This would require some development and precise definition (note: in Unity even a simple new sign-in is a write operation from DB standpoint), but could help a lot: e.g. existing sessions/tokens could be serviced w/o interruptions. But that would require a new feature. HTH, Krzysztof |
From: Laura H. <l....@fz...> - 2025-09-17 09:09:52
|
Hi Krzysztof, Hi Roman, we are currently planning to switch our Unity setup to an HA setup with one master and two workers. This raised the question of how best to proceed with Unity updates: Do all Unity instances have to be stopped and updated at the same time, or can the instances be updated gradually (e.g. within a few hours)? Could the second option cause problems with the database if, for example, the master is already running a newer version of Unity, but the workers are still running an older version? Kind regards, Laura -- "Das Forschungszentrum Jülich stellt zurzeit auf einen neuen Zertifikatsanbieter zum digitalen Signieren von E-Mails um. Während dieser Umstellungsarbeiten kann es vorkommen, dass das DFN Community PKI Zertifikat, mit dem diese E-Mail signiert worden ist, als ungültig angezeigt wird." Large-Scale Data Science Juelich Supercomputing Centre phone: +49 2461 61 6576 fax: +49 2461 61 6656 email: l....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschaeftsfuehrung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Karsten Beneke (stellv. Vorsitzender), Dr. Ir. Pieter Jansens ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
From: Sander A. <sa....@fz...> - 2025-09-03 05:25:14
|
Dear Roman, please find the log attached. Best regards, Sander On Wed, 2025-09-03 at 07:09 +0200, Roman Krysiński wrote: > Dear Sander, > > I'm assuming the problem is manifesting as an error log record. > Would it be possible to provide an exception from unity log? > > Thank you, > Roman > > pon., 1 wrz 2025 o 08:42 Sander Apweiler <sa....@fz...> > napisał(a): > > Dear Roman, > > delivered as part of a regular update would be fine for us. > > > > Thank you very much. > > Sander > > > > On Fri, 2025-08-29 at 12:30 +0200, Roman Krysiński wrote: > > > Dear Sander, > > > > > > We've analyzed the issue of AttributeConsumingServiceIndex in the > > > context of SAML and the specification. > > > > > > Our initial thoughts are that ignoring this parameter by default > > > might be incorrect, as there are conditions under which it should > > > not > > > be omitted. > > > > > > We are leaning towards introducing a configuration option that > > > would > > > allow administrators to decide how to handle this index. > > > Implementing > > > full AttributeConsumingService selection is a much larger scope > > > of > > > work, which is not currently on our roadmap. > > > > > > I would like to ask how urgent this matter is for you? Would a > > > solution delivered as part of a regular update be acceptable to > > > you? > > > > > > Best regards, > > > Roman > > > > > > śr., 27 sie 2025 o 11:57 Sander Apweiler > > > <sa....@fz...> > > > napisał(a): > > > > Dear Krzysztof, > > > > dear Roman, > > > > > > > > one of our colleagues wants to connect Open edX via SAML. Open > > > > edX > > > > send > > > > the AttributeConsumingServiceIndex in the AuthN request, which > > > > is > > > > not > > > > supported by unity. At the moment it returns this to as message > > > > to > > > > the > > > > SP. Since the AtributeConsumingServiceIndex may be just ignored > > > > by > > > > the > > > > IdPs, is there any possibility to make unity ignoring this > > > > instead > > > > of > > > > returning the error message? I can understand that there are > > > > reasons to > > > > return the error message instead of just ignoring it. If not > > > > would > > > > it > > > > be an option to make this configurable by administrators? > > > > > > > > Best regards, > > > > Sander > > > > > > -- Large-Scale Data Science Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Dr. Stephanie Bauer (stellvertretende Vorsitzende), Prof. Dr. Ir. Pieter Jansens, Prof. Dr. Laurens Kuipers ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
From: Roman K. <ro...@un...> - 2025-09-03 05:09:59
|
Dear Sander, I'm assuming the problem is manifesting as an error log record. Would it be possible to provide an exception from unity log? Thank you, Roman pon., 1 wrz 2025 o 08:42 Sander Apweiler <sa....@fz...> napisał(a): > Dear Roman, > delivered as part of a regular update would be fine for us. > > Thank you very much. > Sander > > On Fri, 2025-08-29 at 12:30 +0200, Roman Krysiński wrote: > > Dear Sander, > > > > We've analyzed the issue of AttributeConsumingServiceIndex in the > > context of SAML and the specification. > > > > Our initial thoughts are that ignoring this parameter by default > > might be incorrect, as there are conditions under which it should not > > be omitted. > > > > We are leaning towards introducing a configuration option that would > > allow administrators to decide how to handle this index. Implementing > > full AttributeConsumingService selection is a much larger scope of > > work, which is not currently on our roadmap. > > > > I would like to ask how urgent this matter is for you? Would a > > solution delivered as part of a regular update be acceptable to you? > > > > Best regards, > > Roman > > > > śr., 27 sie 2025 o 11:57 Sander Apweiler <sa....@fz...> > > napisał(a): > > > Dear Krzysztof, > > > dear Roman, > > > > > > one of our colleagues wants to connect Open edX via SAML. Open edX > > > send > > > the AttributeConsumingServiceIndex in the AuthN request, which is > > > not > > > supported by unity. At the moment it returns this to as message to > > > the > > > SP. Since the AtributeConsumingServiceIndex may be just ignored by > > > the > > > IdPs, is there any possibility to make unity ignoring this instead > > > of > > > returning the error message? I can understand that there are > > > reasons to > > > return the error message instead of just ignoring it. If not would > > > it > > > be an option to make this configurable by administrators? > > > > > > Best regards, > > > Sander > > > > > -- > Large-Scale Data Science > Juelich Supercomputing Centre > > phone: +49 2461 61 8847 > fax: +49 2461 61 6656 > email: sa....@fz... > > ----------------------------------------------------------------------- > ----------------------------------------------------------------------- > Forschungszentrum Jülich GmbH > 52425 Jülich > Sitz der Gesellschaft: Jülich > Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 > Vorsitzender des Aufsichtsrats: MinDir Stefan Müller > Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), > Dr. Stephanie Bauer (stellvertretende Vorsitzende), > Prof. Dr. Ir. Pieter Jansens, Prof. Dr. Laurens Kuipers > ----------------------------------------------------------------------- > ----------------------------------------------------------------------- > > > > _______________________________________________ > Unity-idm-discuss mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss > |
From: Sander A. <sa....@fz...> - 2025-09-01 06:42:48
|
Dear Roman, delivered as part of a regular update would be fine for us. Thank you very much. Sander On Fri, 2025-08-29 at 12:30 +0200, Roman Krysiński wrote: > Dear Sander, > > We've analyzed the issue of AttributeConsumingServiceIndex in the > context of SAML and the specification. > > Our initial thoughts are that ignoring this parameter by default > might be incorrect, as there are conditions under which it should not > be omitted. > > We are leaning towards introducing a configuration option that would > allow administrators to decide how to handle this index. Implementing > full AttributeConsumingService selection is a much larger scope of > work, which is not currently on our roadmap. > > I would like to ask how urgent this matter is for you? Would a > solution delivered as part of a regular update be acceptable to you? > > Best regards, > Roman > > śr., 27 sie 2025 o 11:57 Sander Apweiler <sa....@fz...> > napisał(a): > > Dear Krzysztof, > > dear Roman, > > > > one of our colleagues wants to connect Open edX via SAML. Open edX > > send > > the AttributeConsumingServiceIndex in the AuthN request, which is > > not > > supported by unity. At the moment it returns this to as message to > > the > > SP. Since the AtributeConsumingServiceIndex may be just ignored by > > the > > IdPs, is there any possibility to make unity ignoring this instead > > of > > returning the error message? I can understand that there are > > reasons to > > return the error message instead of just ignoring it. If not would > > it > > be an option to make this configurable by administrators? > > > > Best regards, > > Sander > > -- Large-Scale Data Science Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Dr. Stephanie Bauer (stellvertretende Vorsitzende), Prof. Dr. Ir. Pieter Jansens, Prof. Dr. Laurens Kuipers ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
From: Roman K. <ro...@un...> - 2025-08-29 11:01:46
|
Dear Sander, We've analyzed the issue of AttributeConsumingServiceIndex in the context of SAML and the specification. Our initial thoughts are that ignoring this parameter by default might be incorrect, as there are conditions under which it should not be omitted. We are leaning towards introducing a configuration option that would allow administrators to decide how to handle this index. Implementing full AttributeConsumingService selection is a much larger scope of work, which is not currently on our roadmap. I would like to ask how urgent this matter is for you? Would a solution delivered as part of a regular update be acceptable to you? Best regards, Roman śr., 27 sie 2025 o 11:57 Sander Apweiler <sa....@fz...> napisał(a): > Dear Krzysztof, > dear Roman, > > one of our colleagues wants to connect Open edX via SAML. Open edX send > the AttributeConsumingServiceIndex in the AuthN request, which is not > supported by unity. At the moment it returns this to as message to the > SP. Since the AtributeConsumingServiceIndex may be just ignored by the > IdPs, is there any possibility to make unity ignoring this instead of > returning the error message? I can understand that there are reasons to > return the error message instead of just ignoring it. If not would it > be an option to make this configurable by administrators? > > Best regards, > Sander > > -- > Large-Scale Data Science > Juelich Supercomputing Centre > > phone: +49 2461 61 8847 > fax: +49 2461 61 6656 > email: sa....@fz... > > ----------------------------------------------------------------------- > ----------------------------------------------------------------------- > Forschungszentrum Jülich GmbH > 52425 Jülich > Sitz der Gesellschaft: Jülich > Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 > Vorsitzender des Aufsichtsrats: MinDir Stefan Müller > Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), > Dr. Stephanie Bauer (stellvertretende Vorsitzende), > Prof. Dr. Ir. Pieter Jansens, Prof. Dr. Laurens Kuipers > ----------------------------------------------------------------------- > ----------------------------------------------------------------------- > > > > _______________________________________________ > Unity-idm-discuss mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss > |
From: Sander A. <sa....@fz...> - 2025-08-27 09:57:38
|
Dear Krzysztof, dear Roman, one of our colleagues wants to connect Open edX via SAML. Open edX send the AttributeConsumingServiceIndex in the AuthN request, which is not supported by unity. At the moment it returns this to as message to the SP. Since the AtributeConsumingServiceIndex may be just ignored by the IdPs, is there any possibility to make unity ignoring this instead of returning the error message? I can understand that there are reasons to return the error message instead of just ignoring it. If not would it be an option to make this configurable by administrators? Best regards, Sander -- Large-Scale Data Science Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Dr. Stephanie Bauer (stellvertretende Vorsitzende), Prof. Dr. Ir. Pieter Jansens, Prof. Dr. Laurens Kuipers ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
From: Krzysztof B. <kb...@un...> - 2025-07-02 10:09:55
|
Hi Sander, W dniu 2.07.2025 o 07:56, Sander Apweiler pisze: > Hi Krzysztof, > hi Roman, > > I have a short question about the refresh token for public clients > using PKCE. Shall they get a refresh token, if they send the offline > access scope but no openid scope? In manual I found the refresh token > rotation for public clients, but no further information. > > We configured unity to create refresh tokens only on offline access > request. Well, this is not a legitimate request: offline_access scope is defined in OIDC, so a non-OIDC client using it may fail and we are not supporting such setup. That said, I think it should work: such client should get an one time use refresh token. HTH, Krzysztof |
From: Sander A. <sa....@fz...> - 2025-07-02 06:15:03
|
Hi Krzysztof, hi Roman, I have a short question about the refresh token for public clients using PKCE. Shall they get a refresh token, if they send the offline access scope but no openid scope? In manual I found the refresh token rotation for public clients, but no further information. We configured unity to create refresh tokens only on offline access request. Best regards, Sander -- Large-Scale Data Science Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Dr. Stephanie Bauer (stellvertretende Vorsitzende), Prof. Dr. Ir. Pieter Jansens, Prof. Dr. Laurens Kuipers ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
From: Krzysztof B. <kb...@un...> - 2025-06-05 19:30:26
|
Hi Sander, W dniu 16.05.2025 o 07:44, Sander Apweiler pisze: > Good morning Kryzstof, > > 1. I attached a screenshot of the auto process settings. The > Finalization tab has not configuration. Let me know if you need some > others as well. > 2. It happens when you follow the link from the invitation. Clicking on > it in the email or copy it and enter in browser. > 3. I attached the log file, but it has only two get requests. One for > the document and one for the favicon. > 4. As far as we understood, the invitation was send via upman to the > user and the user received it without problems. Just like a normal > email address. So we are pretty sure that the problem is related to the '/' in UpMan project name. Changes in servlet API added quite strict restrictions on encoding '/' in URL paths. We have "legacy-compatible" mode already enabled, however it is failing (there are numerous 3rd party libs which are handling URLs in navigation and the problem is somewhere there). 1. Is it feasible to just restrict use of the '/' character in project names? 2. Can you please retest your scenario on a project w/o '/' in name? My guess is that it should work, including emails with '+'. > About the second error. The steps to reproduce: > 1. Start filling registration form > 2. Wait lets say 5-10 Minutes > 3. Submit the request by clicking on the button Huh, no luck on our side with reproducing that. Sounds like a mistery. Can you please try to isolate this problem (maybe some test project aside)? WOuld be great to have full TRACE level logs of when this happens... Best, Krzysztof |