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...> - 2020-08-25 09:44:44
|
Dear Krzysztof, just as addition how we solved it and maybe as hint where the potential bug is located. I created a new subgroup in console endpoint with the ID from the log. Thereafter I removed the invitation which includes the subgroup and deleted the subgroup again. The invitation tab is still working. So it is problematically if a subgroup is removed and invitations contains this subgroup. Cheers, Sander On Tue, 2020-08-25 at 07:53 +0200, Sander Apweiler wrote: > Good morning Krzysztof, > > I guess we found a bug, at least an issue in upman. We are running > version 3.2.2 where we found the problem. > > We created the full delegation for a group. Within the group > different > subgroups was created, user was invited and added to subgroups. The > manager removed then the different subgroups and created new with > meaningful displaynames. Thereafter unity displays an error when you > switch to the invitation tab (see attached screenshot). The log says > that an old group was not found. I guess the removed subgroups was > not > empty and there was also some outdated invitations also for the > removed > subgroups. > Did you see such a problem before? > > 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 ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Sander A. <sa....@fz...> - 2020-08-25 05:53:52
|
Good morning Krzysztof, I guess we found a bug, at least an issue in upman. We are running version 3.2.2 where we found the problem. We created the full delegation for a group. Within the group different subgroups was created, user was invited and added to subgroups. The manager removed then the different subgroups and created new with meaningful displaynames. Thereafter unity displays an error when you switch to the invitation tab (see attached screenshot). The log says that an old group was not found. I guess the removed subgroups was not empty and there was also some outdated invitations also for the removed subgroups. Did you see such a problem before? 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 ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Krzysztof B. <kb...@un...> - 2020-08-24 07:59:11
|
Hi Sander, W dniu 24.08.2020 o 07:43, Sander Apweiler pisze: > Good morning Krzysztof, > than you very much for the explanation. I understood the problem. This > will sadly not work for us because we expect much usage of subgroups > and we do not want to manage the tree by the unity administrators. hmm, can you elaborate a bit more? I.e. what precisely would not work as expected (feature-wise)? Cheers, Krzysztof |
|
From: Sander A. <sa....@fz...> - 2020-08-24 05:43:49
|
Good morning Krzysztof, than you very much for the explanation. I understood the problem. This will sadly not work for us because we expect much usage of subgroups and we do not want to manage the tree by the unity administrators. Cheers, Sander On Sun, 2020-08-16 at 22:24 +0200, Krzysztof Benedyczak wrote: > Dear Sander, > > > W dniu 12.08.2020 o 07:12, Sander Apweiler pisze: > > Dear Krzysztof, > > at the moment we delegated (via UpMan) the management of /ABC. If > > we > > create further subgroups /ABC/DEF and ABC/GHI (via UpMan) and set > > user2 > > as admin in /ABC/DEF as admin (via UpMan), user2 is also admin in > > /ABC > > and /ABC/GHI. I had a look in our email exchange and we did not > > defined > > it in this way. We just defined that it should be possible to add > > additional administrators. What was the planned design during the > > implementation? > > I think there is some misunderstanding. Upman is solving the problem > of > hierarchical groups management authorization by designating a > selected > group as a "project" for which you can provide management > capabilities > in restricted form by upman. The fact that you can create subgroups > under a project in upman does not mean that in upman suddenly we > have > hierarchical groups authorization defined and implemented. > > So a user can be an upman-admin (project manager formally) of a > project, > which is managed in upman. This means all subgroups will be under > control of this user. > > If you want to support your situation you can, to some extend. But > you > need to designate both /ABC/DEF and /ABC/GHI as separate projects > (delegate them to upman), then after adding user2 project admin > privileges in /ABC/DEF it will be able to manage this project, but > not > GHI, where you can add other user. > > HTH, > 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 ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Krzysztof B. <kb...@un...> - 2020-08-23 09:57:24
|
Dear Subscribers,
We have published a smaller update in the 3.3 series. Besides a minor
fix in the SAML configuration UI, this revision adds two new enhancements:
* REST API allows admin to invalidate or clear user credentials.
* Output profile got access to details of groups, so displayed name of
a group and other attributes can be used to form a SAML or OAuth
response.
More details on the Downloads <https://www.unity-idm.eu/downloads/> page.
Best regards,
Krzysztof
|
|
From: Krzysztof B. <kb...@un...> - 2020-08-16 20:25:10
|
Dear Sander, W dniu 12.08.2020 o 07:12, Sander Apweiler pisze: > Dear Krzysztof, > at the moment we delegated (via UpMan) the management of /ABC. If we > create further subgroups /ABC/DEF and ABC/GHI (via UpMan) and set user2 > as admin in /ABC/DEF as admin (via UpMan), user2 is also admin in /ABC > and /ABC/GHI. I had a look in our email exchange and we did not defined > it in this way. We just defined that it should be possible to add > additional administrators. What was the planned design during the > implementation? I think there is some misunderstanding. Upman is solving the problem of hierarchical groups management authorization by designating a selected group as a "project" for which you can provide management capabilities in restricted form by upman. The fact that you can create subgroups under a project in upman does not mean that in upman suddenly we have hierarchical groups authorization defined and implemented. So a user can be an upman-admin (project manager formally) of a project, which is managed in upman. This means all subgroups will be under control of this user. If you want to support your situation you can, to some extend. But you need to designate both /ABC/DEF and /ABC/GHI as separate projects (delegate them to upman), then after adding user2 project admin privileges in /ABC/DEF it will be able to manage this project, but not GHI, where you can add other user. HTH, Krzysztof |
|
From: Krzysztof B. <kb...@un...> - 2020-08-13 07:37:20
|
W dniu 12.08.2020 o 07:03, Sander Apweiler pisze: > Good morning Krzysztof, > yes this would the only request. I think we can do the transformation > by ourself having this option. It does not make the group creation more > complex for users more complex. OK - ticketized. Thanks, Krzysztof |
|
From: Krzysztof B. <kb...@un...> - 2020-08-12 08:24:06
|
W dniu 12.08.2020 o 06:59, Sander Apweiler pisze: > Good morning Krzysztof, > thanks for the feedback. I guess it is my certificate who makes the > problems. If I understand the manual correctly, I can use the > "unity.saml.requester.requesterCredential" to set it to a certificate > without chain. Is this coorect? yes |
|
From: Sander A. <sa....@fz...> - 2020-08-12 05:12:41
|
Dear Krzysztof, at the moment we delegated (via UpMan) the management of /ABC. If we create further subgroups /ABC/DEF and ABC/GHI (via UpMan) and set user2 as admin in /ABC/DEF as admin (via UpMan), user2 is also admin in /ABC and /ABC/GHI. I had a look in our email exchange and we did not defined it in this way. We just defined that it should be possible to add additional administrators. What was the planned design during the implementation? Cheers, Sander On Tue, 2020-08-11 at 20:37 +0200, Krzysztof Benedyczak wrote: > Sander, > > W dniu 11.08.2020 o 09:39, Sander Apweiler pisze: > > Dear Krzysztof, > > we encountered an issue with the group administrator role. If I > > remember correctly we did not cover the case where we have > > dedicated > > managers for subgroups. At the moment the group administrator is > > administrators of all subgroups and the maingroup itself. > > > > We have now reqeusts for the groupmanagement where multiple > > subgroups > > are managed by dedicated people but they should not have the > > administrator privileges in upper groups. > > > > E.g. > > user1 is admin of /ABC and everything below. > > user2 is admin of /ABC/DEF and everything below but not of /ABC and > > /ABC/GHI > > user3 is admin of /ABC/GHI and everything below but not of /ABC and > > /ABC/DEF > > > > Is it possible to adopt the group administrator role in the way > > that it > > is only granted downwards in the tree and not upwards? > > Upman was supposed to address exactly this use case. E.g. /ABC/DEF > should be delegated (UpMan enabled) and user2 be project's admin. > Then > it will have management capabilities also in /ABC/DEF/whatever but > not > in say /ABC or /ABC/GHI. > > If you want some more "management capabilities" then extending upman > is > the way to proceed. > > 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 ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Sander A. <sa....@fz...> - 2020-08-12 05:03:50
|
Good morning Krzysztof, yes this would the only request. I think we can do the transformation by ourself having this option. It does not make the group creation more complex for users more complex. Cheers, Sander On Tue, 2020-08-11 at 20:30 +0200, Krzysztof Benedyczak wrote: > Hi Sander, > > W dniu 11.08.2020 o 09:26, Sander Apweiler pisze: > > Hi Krzysztof, > > I think, having access to the group-displaynames in the > > translationprofile would be very helpful. In this case we could > > transform them with mvel statments to our needs. E.g. We could > > transform /ABC/DEF into urn:geant_h- > > df.de:group:MyTestGroup:subgroup1#... > > > > where /ABC is MyTestGroup and .../DEF subgroup1 within MyTestGroup. > > > > In this case you do not need to carry about the released > > information or > > change the unity behaviour. Maybe other users want/need the current > > behaviour. > > > > Having this possibility would allow to create the entitlement > > according > > to AARC G002 automatically for all groups, instead using attribute > > statements. > > OK, so that's the only request? I.e. to be able to access in output > profile the displayed name of a group, giving its internal name as > an > argument, as follows: > > grpDisplayedName['/ABC'] > > returning: > > MyTestGroup > > Can you confirm please? Or there is more that needs to be changed? > > Thanks > 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 ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Sander A. <sa....@fz...> - 2020-08-12 05:00:07
|
Good morning Krzysztof, thanks for the feedback. I guess it is my certificate who makes the problems. If I understand the manual correctly, I can use the "unity.saml.requester.requesterCredential" to set it to a certificate without chain. Is this coorect? Cheers, Sander On Tue, 2020-08-11 at 20:25 +0200, Krzysztof Benedyczak wrote: > Sander, > > W dniu 11.08.2020 o 08:37, Sander Apweiler pisze: > > Dear Krzysztof, > > I attached the extended log. I saw some problems with "Response > > header > > too large" but I'm not sure who send this header. > > Yes, that's certainly the reason. The too big header is the > Location: > header used in redirect which Unity tries to do to authenticate the > user > with remote SAML IdP. > > This header contains compressed SAML request, but unfortunately it > is > too big to fit into a header. There is perhaps 8kB limit (or 10kB > maybe), without option to be reconfigured in the HTTP server. Even > if > there was an option to support bigger headers, it will be a lottery > with > proxies and browsers. In general 10kB is assumed to be safe max. > > > So you can either: > > * reconfigure (or trigger reconfiguration) this SP to use SAML POST > binding, or > > * have shorter cert chain for the signature - the 3 certs long chain > embedded in the request constitutes the most of the request size. > > Cheers, > KB > > > > > Cheers, > > Sander > > > > I attached the On Mon, 2020-08-10 at 19:15 +0200, Krzysztof > > Benedyczak > > wrote: > > > Dear Sander, > > > > > > W dniu 10.08.2020 o 06:58, Sander Apweiler pisze: > > > > Dear Krzysztof, > > > > we encountered an issue with the SAML IdP of CLARIN. We > > > > connected > > > > this > > > > IdP on two instance (b2access.eudat.eu and b2access- > > > > integration.fz- > > > > juelich.de), both are running unity 3.2.2. Both are configured > > > > in > > > > the > > > > same way: > > > > > > > > unity.saml.requester.metadataSource.clarin.url= > > > > https://infra.clarin.eu/aai/prod_md_about_clarin_erics_idp.xml > > > > unity.saml.requester.metadataSource.clarin.perMetadataTranslati > > > > onPr > > > > ofile=clarinIdp > > > > unity.saml.requester.metadataSource.clarin.perMetadataRegistrat > > > > ionF > > > > orm=CLARIN-IDP > > > > > > > > On the integration instance it works fine, but on the eudat.eu > > > > instance > > > > it stops since at least last week (here we found this issue) > > > > after > > > > selecting the IdP with the URL: > > > > > > > > https://b2access.eudat.eu/home/?redirectToIdP=d9c934ff-1b81-40cd-a77d-ee1c6c26a3ef > > > > > > > > The log file does not provide any further information (trace). > > > > I > > > > attached the log and the SAML flow information from a user, > > > > where > > > > you > > > > see a 500 error. Did you see this problem before? We dropped > > > > already > > > > the IdP and add it new. > > > As this is easily reproducible (I was able on you instance > > > without > > > any > > > trouble): > > > > > > 1. pls try to obtain logged error from your server. Try to enable > > > even > > > full TRACE (all subsystems) for a sec, and trigger the issue. > > > There > > > should be something logged on jetty or vaadin level > > > > > > 2. if you fail with the above try to provide your authenticator > > > configuration, so that it can be configured on my end. Then I can > > > try > > > to > > > debug it. It would be perfect if you replicated this problem with > > > other > > > environment - there must be some difference between your testbed > > > and > > > prod instance. > > > > > > > > > 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 ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Krzysztof B. <kb...@un...> - 2020-08-11 18:38:10
|
Sander, W dniu 11.08.2020 o 09:39, Sander Apweiler pisze: > Dear Krzysztof, > we encountered an issue with the group administrator role. If I > remember correctly we did not cover the case where we have dedicated > managers for subgroups. At the moment the group administrator is > administrators of all subgroups and the maingroup itself. > > We have now reqeusts for the groupmanagement where multiple subgroups > are managed by dedicated people but they should not have the > administrator privileges in upper groups. > > E.g. > user1 is admin of /ABC and everything below. > user2 is admin of /ABC/DEF and everything below but not of /ABC and > /ABC/GHI > user3 is admin of /ABC/GHI and everything below but not of /ABC and > /ABC/DEF > > Is it possible to adopt the group administrator role in the way that it > is only granted downwards in the tree and not upwards? Upman was supposed to address exactly this use case. E.g. /ABC/DEF should be delegated (UpMan enabled) and user2 be project's admin. Then it will have management capabilities also in /ABC/DEF/whatever but not in say /ABC or /ABC/GHI. If you want some more "management capabilities" then extending upman is the way to proceed. Best, Krzysztof |
|
From: Krzysztof B. <kb...@un...> - 2020-08-11 18:30:44
|
Hi Sander, W dniu 11.08.2020 o 09:26, Sander Apweiler pisze: > Hi Krzysztof, > I think, having access to the group-displaynames in the > translationprofile would be very helpful. In this case we could > transform them with mvel statments to our needs. E.g. We could > transform /ABC/DEF into urn:geant_h- > df.de:group:MyTestGroup:subgroup1#... > > where /ABC is MyTestGroup and .../DEF subgroup1 within MyTestGroup. > > In this case you do not need to carry about the released information or > change the unity behaviour. Maybe other users want/need the current > behaviour. > > Having this possibility would allow to create the entitlement according > to AARC G002 automatically for all groups, instead using attribute > statements. OK, so that's the only request? I.e. to be able to access in output profile the displayed name of a group, giving its internal name as an argument, as follows: grpDisplayedName['/ABC'] returning: MyTestGroup Can you confirm please? Or there is more that needs to be changed? Thanks Krzysztof |
|
From: Krzysztof B. <kb...@un...> - 2020-08-11 18:25:20
|
Sander, W dniu 11.08.2020 o 08:37, Sander Apweiler pisze: > Dear Krzysztof, > I attached the extended log. I saw some problems with "Response header > too large" but I'm not sure who send this header. Yes, that's certainly the reason. The too big header is the Location: header used in redirect which Unity tries to do to authenticate the user with remote SAML IdP. This header contains compressed SAML request, but unfortunately it is too big to fit into a header. There is perhaps 8kB limit (or 10kB maybe), without option to be reconfigured in the HTTP server. Even if there was an option to support bigger headers, it will be a lottery with proxies and browsers. In general 10kB is assumed to be safe max. So you can either: * reconfigure (or trigger reconfiguration) this SP to use SAML POST binding, or * have shorter cert chain for the signature - the 3 certs long chain embedded in the request constitutes the most of the request size. Cheers, KB > Cheers, > Sander > > I attached the On Mon, 2020-08-10 at 19:15 +0200, Krzysztof Benedyczak > wrote: >> Dear Sander, >> >> W dniu 10.08.2020 o 06:58, Sander Apweiler pisze: >>> Dear Krzysztof, >>> we encountered an issue with the SAML IdP of CLARIN. We connected >>> this >>> IdP on two instance (b2access.eudat.eu and b2access-integration.fz- >>> juelich.de), both are running unity 3.2.2. Both are configured in >>> the >>> same way: >>> >>> unity.saml.requester.metadataSource.clarin.url= >>> https://infra.clarin.eu/aai/prod_md_about_clarin_erics_idp.xml >>> unity.saml.requester.metadataSource.clarin.perMetadataTranslationPr >>> ofile=clarinIdp >>> unity.saml.requester.metadataSource.clarin.perMetadataRegistrationF >>> orm=CLARIN-IDP >>> >>> On the integration instance it works fine, but on the eudat.eu >>> instance >>> it stops since at least last week (here we found this issue) after >>> selecting the IdP with the URL: >>> >>> https://b2access.eudat.eu/home/?redirectToIdP=d9c934ff-1b81-40cd-a77d-ee1c6c26a3ef >>> >>> The log file does not provide any further information (trace). I >>> attached the log and the SAML flow information from a user, where >>> you >>> see a 500 error. Did you see this problem before? We dropped >>> already >>> the IdP and add it new. >> As this is easily reproducible (I was able on you instance without >> any >> trouble): >> >> 1. pls try to obtain logged error from your server. Try to enable >> even >> full TRACE (all subsystems) for a sec, and trigger the issue. There >> should be something logged on jetty or vaadin level >> >> 2. if you fail with the above try to provide your authenticator >> configuration, so that it can be configured on my end. Then I can try >> to >> debug it. It would be perfect if you replicated this problem with >> other >> environment - there must be some difference between your testbed and >> prod instance. >> >> >> Cheers >> Krzysztof >> |
|
From: Sander A. <sa....@fz...> - 2020-08-11 07:39:50
|
Dear Krzysztof, we encountered an issue with the group administrator role. If I remember correctly we did not cover the case where we have dedicated managers for subgroups. At the moment the group administrator is administrators of all subgroups and the maingroup itself. We have now reqeusts for the groupmanagement where multiple subgroups are managed by dedicated people but they should not have the administrator privileges in upper groups. E.g. user1 is admin of /ABC and everything below. user2 is admin of /ABC/DEF and everything below but not of /ABC and /ABC/GHI user3 is admin of /ABC/GHI and everything below but not of /ABC and /ABC/DEF Is it possible to adopt the group administrator role in the way that it is only granted downwards in the tree and not upwards? 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 ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Sander A. <sa....@fz...> - 2020-08-11 07:26:19
|
Hi Krzysztof, I think, having access to the group-displaynames in the translationprofile would be very helpful. In this case we could transform them with mvel statments to our needs. E.g. We could transform /ABC/DEF into urn:geant_h- df.de:group:MyTestGroup:subgroup1#... where /ABC is MyTestGroup and .../DEF subgroup1 within MyTestGroup. In this case you do not need to carry about the released information or change the unity behaviour. Maybe other users want/need the current behaviour. Having this possibility would allow to create the entitlement according to AARC G002 automatically for all groups, instead using attribute statements. Best regards, Sander On Tue, 2020-08-11 at 09:12 +0200, Marcus Hardt wrote: > On 08/10/20 19:26, Krzysztof Benedyczak wrote: > > Hi Sander, > > > > W dniu 04.08.2020 o 15:01, Sander Apweiler pisze: > > > Hi Krzysztof, > > > > > > On Tue, 2020-08-04 at 09:56 +0200, Krzysztof Benedyczak wrote: > > > > Morning Sander, > > > > > > > > W dniu 03.08.2020 o 08:39, Sander Apweiler pisze: > > > > > Good morning Krzysztof, > > > > > I agree that identifiers are needed. But is there a > > > > > possibility to > > > > > grab > > > > > the displayname of a group, e.g. in output translation > > > > > profile? In > > > > > this > > > > > case we could release the group membership information like > > > > > the > > > > > group > > > > > administrators and service providers would expect them. > > > > > > > > > > I'll give you an example. We have a group m-team which is > > > > > managed > > > > > by a > > > > > group administrator. He created a subgroup feudal-developers > > > > > and > > > > > asked > > > > > specific service providers to support his group /m- > > > > > team/feudal- > > > > > developers but the service provider only see /m-team/NNE09. > > > > > > > > > > Having the possibility to access the displayname, we could > > > > > create a > > > > > new > > > > > attribute containing the expected information. > > > > Hmm I wonder whether this is the right path. Shouldn't this be > > > > opposite? > > > I would agree in a very closed SP audience, only. If you have a > > > broader > > > audience which are part of multiple federations, this may become > > > problematically. You would need to have a unique identifier > > > across > > > several IdPs, which can not be guaranteed. And in this case you > > > do not > > > need to carry about the uniqueness of the information anymore. > > > > I don't udnerstand. You have many clients (SPs), OK. There is Upman > > instance > > with some groups. SPs get attribute with group id (say /zxc). Where > > is the > > problem that instead you need "/my-important-group"? > > > > I don't understand the passage about unique identifier across > > several IdPs? > > There are multiple points. > > Firstly, if SPs only obtain an identifier (rather than a name) it > will be very difficult to make sure that name is the same everywhere. > > That is why everybody simply sent a list of groups. > > Then people realized that different IdPs might issue the same group > name > in different contexts. That is why we wrote AARC-G002, that defines > globally unique group names (using the eduperson_entitlement) > > Then came reality, that struck us the fact that some SPs (the stupid > SPs > from below) simply display "the entry" (i.e. either group or > eduperson_entitlement) to the user. For that GUIDs suck, for those > group > lists are acceptable, but those services can only bind to one proxy. > > It be useful (I guess) for Sander, if the groups in unity correspond > uniquely to their G002 representation. > > Unity internal identifiers should not be exposed outside of unity. > > > > > Another problem are stupid SPs which consume the information > > > directly > > > and displays it to the users. One example is Nextcloud which is > > > able to > > > consume the groups from IdP (unity in this case). But Nextcloud > > > will > > > create the groups with the names released by the IdP and if the > > > user > > > want to share information with the group, they need to know the > > > identifier. > > > > Properly this should be realized as follows: IdP (upman) releases > > group id > > (hidden to the user) and displayed name (presented). Internally > > group id is > > used. > > > > If this is not doable (i.e. the software can not distinguish > > identifier from > > its displaied form) the only thing we can do is to have same > > displayed name > > and group id. > > I'm not sure why the identifier needs to be exposed at all, but there > may > be use cases that I don't know. > > M. > > > > This would be extra feature in upman, an extra mode: group creation > > would > > use displayed name as group id. We can do it, but note that as soon > > as > > somebody changes group displayed name in upman (or unity console) > > you will > > have semantic mess in the infrastructure. > > > > Does the above address your problem? > > > > Cheers, > > 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 ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Marcus H. <ha...@ki...> - 2020-08-11 07:12:53
|
On 08/10/20 19:26, Krzysztof Benedyczak wrote: > Hi Sander, > > W dniu 04.08.2020 o 15:01, Sander Apweiler pisze: > > Hi Krzysztof, > > > > On Tue, 2020-08-04 at 09:56 +0200, Krzysztof Benedyczak wrote: > > > Morning Sander, > > > > > > W dniu 03.08.2020 o 08:39, Sander Apweiler pisze: > > > > Good morning Krzysztof, > > > > I agree that identifiers are needed. But is there a possibility to > > > > grab > > > > the displayname of a group, e.g. in output translation profile? In > > > > this > > > > case we could release the group membership information like the > > > > group > > > > administrators and service providers would expect them. > > > > > > > > I'll give you an example. We have a group m-team which is managed > > > > by a > > > > group administrator. He created a subgroup feudal-developers and > > > > asked > > > > specific service providers to support his group /m-team/feudal- > > > > developers but the service provider only see /m-team/NNE09. > > > > > > > > Having the possibility to access the displayname, we could create a > > > > new > > > > attribute containing the expected information. > > > Hmm I wonder whether this is the right path. Shouldn't this be > > > opposite? > > I would agree in a very closed SP audience, only. If you have a broader > > audience which are part of multiple federations, this may become > > problematically. You would need to have a unique identifier across > > several IdPs, which can not be guaranteed. And in this case you do not > > need to carry about the uniqueness of the information anymore. > > I don't udnerstand. You have many clients (SPs), OK. There is Upman instance > with some groups. SPs get attribute with group id (say /zxc). Where is the > problem that instead you need "/my-important-group"? > > I don't understand the passage about unique identifier across several IdPs? There are multiple points. Firstly, if SPs only obtain an identifier (rather than a name) it will be very difficult to make sure that name is the same everywhere. That is why everybody simply sent a list of groups. Then people realized that different IdPs might issue the same group name in different contexts. That is why we wrote AARC-G002, that defines globally unique group names (using the eduperson_entitlement) Then came reality, that struck us the fact that some SPs (the stupid SPs from below) simply display "the entry" (i.e. either group or eduperson_entitlement) to the user. For that GUIDs suck, for those group lists are acceptable, but those services can only bind to one proxy. It be useful (I guess) for Sander, if the groups in unity correspond uniquely to their G002 representation. Unity internal identifiers should not be exposed outside of unity. > > Another problem are stupid SPs which consume the information directly > > and displays it to the users. One example is Nextcloud which is able to > > consume the groups from IdP (unity in this case). But Nextcloud will > > create the groups with the names released by the IdP and if the user > > want to share information with the group, they need to know the > > identifier. > > Properly this should be realized as follows: IdP (upman) releases group id > (hidden to the user) and displayed name (presented). Internally group id is > used. > > If this is not doable (i.e. the software can not distinguish identifier from > its displaied form) the only thing we can do is to have same displayed name > and group id. I'm not sure why the identifier needs to be exposed at all, but there may be use cases that I don't know. M. > This would be extra feature in upman, an extra mode: group creation would > use displayed name as group id. We can do it, but note that as soon as > somebody changes group displayed name in upman (or unity console) you will > have semantic mess in the infrastructure. > > Does the above address your problem? > > Cheers, > Krzysztof > > > > _______________________________________________ > Unity-idm-discuss mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss -- Marcus. |
|
From: Sander A. <sa....@fz...> - 2020-08-11 06:38:07
|
Dear Krzysztof, I attached the extended log. I saw some problems with "Response header too large" but I'm not sure who send this header. Cheers, Sander I attached the On Mon, 2020-08-10 at 19:15 +0200, Krzysztof Benedyczak wrote: > Dear Sander, > > W dniu 10.08.2020 o 06:58, Sander Apweiler pisze: > > Dear Krzysztof, > > we encountered an issue with the SAML IdP of CLARIN. We connected > > this > > IdP on two instance (b2access.eudat.eu and b2access-integration.fz- > > juelich.de), both are running unity 3.2.2. Both are configured in > > the > > same way: > > > > unity.saml.requester.metadataSource.clarin.url= > > https://infra.clarin.eu/aai/prod_md_about_clarin_erics_idp.xml > > unity.saml.requester.metadataSource.clarin.perMetadataTranslationPr > > ofile=clarinIdp > > unity.saml.requester.metadataSource.clarin.perMetadataRegistrationF > > orm=CLARIN-IDP > > > > On the integration instance it works fine, but on the eudat.eu > > instance > > it stops since at least last week (here we found this issue) after > > selecting the IdP with the URL: > > > > https://b2access.eudat.eu/home/?redirectToIdP=d9c934ff-1b81-40cd-a77d-ee1c6c26a3ef > > > > The log file does not provide any further information (trace). I > > attached the log and the SAML flow information from a user, where > > you > > see a 500 error. Did you see this problem before? We dropped > > already > > the IdP and add it new. > > As this is easily reproducible (I was able on you instance without > any > trouble): > > 1. pls try to obtain logged error from your server. Try to enable > even > full TRACE (all subsystems) for a sec, and trigger the issue. There > should be something logged on jetty or vaadin level > > 2. if you fail with the above try to provide your authenticator > configuration, so that it can be configured on my end. Then I can try > to > debug it. It would be perfect if you replicated this problem with > other > environment - there must be some difference between your testbed and > prod instance. > > > 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 ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Krzysztof B. <kb...@un...> - 2020-08-10 17:27:12
|
Hi Sander, W dniu 04.08.2020 o 15:01, Sander Apweiler pisze: > Hi Krzysztof, > > On Tue, 2020-08-04 at 09:56 +0200, Krzysztof Benedyczak wrote: >> Morning Sander, >> >> W dniu 03.08.2020 o 08:39, Sander Apweiler pisze: >>> Good morning Krzysztof, >>> I agree that identifiers are needed. But is there a possibility to >>> grab >>> the displayname of a group, e.g. in output translation profile? In >>> this >>> case we could release the group membership information like the >>> group >>> administrators and service providers would expect them. >>> >>> I'll give you an example. We have a group m-team which is managed >>> by a >>> group administrator. He created a subgroup feudal-developers and >>> asked >>> specific service providers to support his group /m-team/feudal- >>> developers but the service provider only see /m-team/NNE09. >>> >>> Having the possibility to access the displayname, we could create a >>> new >>> attribute containing the expected information. >> Hmm I wonder whether this is the right path. Shouldn't this be >> opposite? > I would agree in a very closed SP audience, only. If you have a broader > audience which are part of multiple federations, this may become > problematically. You would need to have a unique identifier across > several IdPs, which can not be guaranteed. And in this case you do not > need to carry about the uniqueness of the information anymore. I don't udnerstand. You have many clients (SPs), OK. There is Upman instance with some groups. SPs get attribute with group id (say /zxc). Where is the problem that instead you need "/my-important-group"? I don't understand the passage about unique identifier across several IdPs? > Another problem are stupid SPs which consume the information directly > and displays it to the users. One example is Nextcloud which is able to > consume the groups from IdP (unity in this case). But Nextcloud will > create the groups with the names released by the IdP and if the user > want to share information with the group, they need to know the > identifier. Properly this should be realized as follows: IdP (upman) releases group id (hidden to the user) and displayed name (presented). Internally group id is used. If this is not doable (i.e. the software can not distinguish identifier from its displaied form) the only thing we can do is to have same displayed name and group id. This would be extra feature in upman, an extra mode: group creation would use displayed name as group id. We can do it, but note that as soon as somebody changes group displayed name in upman (or unity console) you will have semantic mess in the infrastructure. Does the above address your problem? Cheers, Krzysztof |
|
From: Krzysztof B. <kb...@un...> - 2020-08-10 17:15:58
|
Dear Sander, W dniu 10.08.2020 o 06:58, Sander Apweiler pisze: > Dear Krzysztof, > we encountered an issue with the SAML IdP of CLARIN. We connected this > IdP on two instance (b2access.eudat.eu and b2access-integration.fz- > juelich.de), both are running unity 3.2.2. Both are configured in the > same way: > > unity.saml.requester.metadataSource.clarin.url=https://infra.clarin.eu/aai/prod_md_about_clarin_erics_idp.xml > unity.saml.requester.metadataSource.clarin.perMetadataTranslationProfile=clarinIdp > unity.saml.requester.metadataSource.clarin.perMetadataRegistrationForm=CLARIN-IDP > > On the integration instance it works fine, but on the eudat.eu instance > it stops since at least last week (here we found this issue) after > selecting the IdP with the URL: > > https://b2access.eudat.eu/home/?redirectToIdP=d9c934ff-1b81-40cd-a77d-ee1c6c26a3ef > > The log file does not provide any further information (trace). I > attached the log and the SAML flow information from a user, where you > see a 500 error. Did you see this problem before? We dropped already > the IdP and add it new. As this is easily reproducible (I was able on you instance without any trouble): 1. pls try to obtain logged error from your server. Try to enable even full TRACE (all subsystems) for a sec, and trigger the issue. There should be something logged on jetty or vaadin level 2. if you fail with the above try to provide your authenticator configuration, so that it can be configured on my end. Then I can try to debug it. It would be perfect if you replicated this problem with other environment - there must be some difference between your testbed and prod instance. Cheers Krzysztof |
|
From: Sander A. <sa....@fz...> - 2020-08-10 04:58:46
|
Dear Krzysztof, we encountered an issue with the SAML IdP of CLARIN. We connected this IdP on two instance (b2access.eudat.eu and b2access-integration.fz- juelich.de), both are running unity 3.2.2. Both are configured in the same way: unity.saml.requester.metadataSource.clarin.url=https://infra.clarin.eu/aai/prod_md_about_clarin_erics_idp.xml unity.saml.requester.metadataSource.clarin.perMetadataTranslationProfile=clarinIdp unity.saml.requester.metadataSource.clarin.perMetadataRegistrationForm=CLARIN-IDP On the integration instance it works fine, but on the eudat.eu instance it stops since at least last week (here we found this issue) after selecting the IdP with the URL: https://b2access.eudat.eu/home/?redirectToIdP=d9c934ff-1b81-40cd-a77d-ee1c6c26a3ef The log file does not provide any further information (trace). I attached the log and the SAML flow information from a user, where you see a 500 error. Did you see this problem before? We dropped already the IdP and add it new. 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 ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Sander A. <sa....@fz...> - 2020-08-04 13:01:56
|
Hi Krzysztof, On Tue, 2020-08-04 at 09:56 +0200, Krzysztof Benedyczak wrote: > Morning Sander, > > W dniu 03.08.2020 o 08:39, Sander Apweiler pisze: > > Good morning Krzysztof, > > I agree that identifiers are needed. But is there a possibility to > > grab > > the displayname of a group, e.g. in output translation profile? In > > this > > case we could release the group membership information like the > > group > > administrators and service providers would expect them. > > > > I'll give you an example. We have a group m-team which is managed > > by a > > group administrator. He created a subgroup feudal-developers and > > asked > > specific service providers to support his group /m-team/feudal- > > developers but the service provider only see /m-team/NNE09. > > > > Having the possibility to access the displayname, we could create a > > new > > attribute containing the expected information. > > Hmm I wonder whether this is the right path. Shouldn't this be > opposite? I would agree in a very closed SP audience, only. If you have a broader audience which are part of multiple federations, this may become problematically. You would need to have a unique identifier across several IdPs, which can not be guaranteed. And in this case you do not need to carry about the uniqueness of the information anymore. Another problem are stupid SPs which consume the information directly and displays it to the users. One example is Nextcloud which is able to consume the groups from IdP (unity in this case). But Nextcloud will create the groups with the names released by the IdP and if the user want to share information with the group, they need to know the identifier. The next scenario is that a research community might have their groups on several environments and want to have the same name on every services. Here does the identifier also not work. Sadly such small things might make the decision if the service is used or not. To make it short there are scenarios where the opposite flow does not work. > I.e. on output profile/protocol etc I would rather send 'NNE09' as > the > identifier and configure all policies around this - this is stable > identifier. If you program around displayed name then... who knows > what > needs to be updated after some upman admin "improves" the displayed > name? Changing the display name would be the the short was for creating a new group with the same members and removing the old group. Which would lead of course to changed access permissions on the SP, which use the group based access. Having no access to the resources are also possible in this case. > > I agree that giving access to displayed name (also in output > profile) > makes sense in general, to add some human readable context (useful > e.g. > for debuggin, initial config) but the base thing for me is the > stable > identifier. > > What do you think? I agree that having a unique identifier is necessary for unity. But there are different scenarios where the displayname need to be released to the service providers instead of the identifier. Cheers, Sander > > KB > > -- 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 ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Krzysztof B. <kb...@un...> - 2020-08-04 07:56:43
|
Morning Sander, W dniu 03.08.2020 o 08:39, Sander Apweiler pisze: > Good morning Krzysztof, > I agree that identifiers are needed. But is there a possibility to grab > the displayname of a group, e.g. in output translation profile? In this > case we could release the group membership information like the group > administrators and service providers would expect them. > > I'll give you an example. We have a group m-team which is managed by a > group administrator. He created a subgroup feudal-developers and asked > specific service providers to support his group /m-team/feudal- > developers but the service provider only see /m-team/NNE09. > > Having the possibility to access the displayname, we could create a new > attribute containing the expected information. Hmm I wonder whether this is the right path. Shouldn't this be opposite? I.e. on output profile/protocol etc I would rather send 'NNE09' as the identifier and configure all policies around this - this is stable identifier. If you program around displayed name then... who knows what needs to be updated after some upman admin "improves" the displayed name? I agree that giving access to displayed name (also in output profile) makes sense in general, to add some human readable context (useful e.g. for debuggin, initial config) but the base thing for me is the stable identifier. What do you think? KB |
|
From: Marcus H. <ha...@ki...> - 2020-08-03 07:21:46
|
On 08/03/20 09:20, Marcus Hardt wrote: > On 08/01/20 23:57, Krzysztof Benedyczak wrote: > > Sander, > > > > W dniu 27.07.2020 o 07:36, Sander Apweiler pisze: > > > Good morning Krzysztof, > > > > > > On Sat, 2020-07-25 at 16:03 +0200, Krzysztof Benedyczak wrote: > > > > Hi Sander, > > > > > > > > W dniu 20.07.2020 o 12:34, Sander Apweiler pisze: > > > > > Yes it is stored. See attachment. > > > > > > 2. what are the settings in authentication UI configuration? Do > > > > > > you > > > > > > have > > > > > > "show last used option..." selected on the endpoint in question? > > > > > Do you mean this one: unity.endpoint.web.authnLastOptionOnlyLayout? > > > > > We use the default value. > > > > No I meant this: > > > > > > > > unity.endpoint.web .authnShowLastOptionOnly > > > > > > > > do you have it set to true? Can you check up your endpoint config in > > > > Console? > > > The option is not set in config files, so I guess it uses the default > > > value true. Within the configuration in console endpoint, it indicates > > > that it is true. See attachments. > > > > Anyway this works for me. I can only suspect some problem with authN > > > > options autogenerated from saml metadata. > > > > > > > > > > 3. it doesn't work for saml only or for arbitrary authentication > > > > > > options? > > > > > It does not work for all endpoints. > > > > > > > > > I meant: whether this problem occurs only with SAML sign-in using > > > > some federation, or it also doesn't work with other authN options > > > > (e.g. password)? > > > It is working for no authN. Not for SAML federation and also not for > > > password, where password authentication is possible. > > > > > Well, I've tried this in several variants and all were working on my end > > flawlessly. > > > > I can't give you any better hint, then to try to minimize the problem area. > > Perhaps you can try to setup a simple test endpoint (e.g. homeUI) add to it > > 2 authN options (e.g. password and one oauth) and try on it? If it works (by > > far it should) then I'd try to add more setting from an endpoint which is > > not working. If it doesn't work, let me know the precise config of the > > endpoint. > > From what I saw, the problem does not show with every SAML IdP. I saw a > screenshare of DKFZ users where it worked, but I think that it does not > work properly for KIT and HMGU users. Sorry, I meant HZDR users. > -- > Marcus. |
|
From: Marcus H. <ha...@ki...> - 2020-08-03 07:20:50
|
On 08/01/20 23:57, Krzysztof Benedyczak wrote: > Sander, > > W dniu 27.07.2020 o 07:36, Sander Apweiler pisze: > > Good morning Krzysztof, > > > > On Sat, 2020-07-25 at 16:03 +0200, Krzysztof Benedyczak wrote: > > > Hi Sander, > > > > > > W dniu 20.07.2020 o 12:34, Sander Apweiler pisze: > > > > Yes it is stored. See attachment. > > > > > 2. what are the settings in authentication UI configuration? Do > > > > > you > > > > > have > > > > > "show last used option..." selected on the endpoint in question? > > > > Do you mean this one: unity.endpoint.web.authnLastOptionOnlyLayout? > > > > We use the default value. > > > No I meant this: > > > > > > unity.endpoint.web .authnShowLastOptionOnly > > > > > > do you have it set to true? Can you check up your endpoint config in > > > Console? > > The option is not set in config files, so I guess it uses the default > > value true. Within the configuration in console endpoint, it indicates > > that it is true. See attachments. > > > Anyway this works for me. I can only suspect some problem with authN > > > options autogenerated from saml metadata. > > > > > > > > 3. it doesn't work for saml only or for arbitrary authentication > > > > > options? > > > > It does not work for all endpoints. > > > > > > > I meant: whether this problem occurs only with SAML sign-in using > > > some federation, or it also doesn't work with other authN options > > > (e.g. password)? > > It is working for no authN. Not for SAML federation and also not for > > password, where password authentication is possible. > > > Well, I've tried this in several variants and all were working on my end > flawlessly. > > I can't give you any better hint, then to try to minimize the problem area. > Perhaps you can try to setup a simple test endpoint (e.g. homeUI) add to it > 2 authN options (e.g. password and one oauth) and try on it? If it works (by > far it should) then I'd try to add more setting from an endpoint which is > not working. If it doesn't work, let me know the precise config of the > endpoint. From what I saw, the problem does not show with every SAML IdP. I saw a screenshare of DKFZ users where it worked, but I think that it does not work properly for KIT and HMGU users. -- Marcus. |
