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
(2) |
Sep
(8) |
Oct
(1) |
Nov
|
Dec
|
|
From: Krzysztof B. <kb...@un...> - 2020-09-21 07:05:09
|
Hi Sander, W dniu 21.09.2020 o 07:22, Sander Apweiler pisze: > Good morning Krzysztof, > I own you still an answer on your last question. > > On Wed, 2020-09-16 at 12:35 +0200, Krzysztof Benedyczak wrote: >> Hello Sander, >> >> W dniu 15.09.2020 o 09:55, Sander Apweiler pisze: >>> Hello Krzysztof, >>> I have some further information about this issue. The KIT IdP, who >>> renews its certificate, offers at the moment two signing >>> certificates >>> in the federation metadata. The old one and the new one. This is a >>> common way for the certificate renewal [1]. It seems that unity >>> only >>> supports one of them and this creates the mismatch. Unity should >>> support all certificates which are provided via the IdP metadata. >>> >>> This rollover procedure should avoid outages for the users during >>> the >>> update procedure. Especially when you use federations it took time >>> until the information reaches the other end of the chain. In best >>> case >>> only a few minutes, when the information reaches the next level >>> before >>> the level above fetches the information. In bad case it takes >>> several >>> days, if the new information only fetched once per day. >> We have an old ticket (2017 (!)) about the certificates not being >> updated after metadata change. The ticket has a note that I was >> unable >> to reproduce it despite of several tries. >> >> The situation with multiple certificates of an IdP should work - it >> is >> supported. I.e. if IdP metadata advertises more then one >> certificate, >> then Unity should accept all of them. This feature is I think less >> tested so I can suspect that there may some bug in it. >> >> I can add more detailed logging what I'll do for the next revision - >> it >> should help to track down the problem. We have also pending ticket to >> be >> able to see in details the runtime (effective) list of trusted IdPs >> for >> a SAML authenticator - but that's a bit bigger work, not planned in >> near >> term. >> >>> Is it possible that unity supports this common rollover mechanism >>> for >>> its own certificates in future? >> Yes, why not. We can add a new option to IdP configuration, "former >> credential" which would be used for metadata only. Sounds rather >> easy. >> Do you consider this also for SP (i.e. Unity SAML authenticator)? > Yes it would be also effect the SP. I guess, if unity is used as Proxy, > in most cases the same certificate is used for IdP and SP part. And you > need to do the rollover in the same way for both. That was my assumption too, agreed. One extra note: this task is more involving than my first thought was: we also need to support decryption, and we need to be able to decrypt with either of the certificates. Cheers, Krzysztof |
|
From: Sander A. <sa....@fz...> - 2020-09-21 05:22:51
|
Good morning Krzysztof, I own you still an answer on your last question. On Wed, 2020-09-16 at 12:35 +0200, Krzysztof Benedyczak wrote: > Hello Sander, > > W dniu 15.09.2020 o 09:55, Sander Apweiler pisze: > > Hello Krzysztof, > > I have some further information about this issue. The KIT IdP, who > > renews its certificate, offers at the moment two signing > > certificates > > in the federation metadata. The old one and the new one. This is a > > common way for the certificate renewal [1]. It seems that unity > > only > > supports one of them and this creates the mismatch. Unity should > > support all certificates which are provided via the IdP metadata. > > > > This rollover procedure should avoid outages for the users during > > the > > update procedure. Especially when you use federations it took time > > until the information reaches the other end of the chain. In best > > case > > only a few minutes, when the information reaches the next level > > before > > the level above fetches the information. In bad case it takes > > several > > days, if the new information only fetched once per day. > > We have an old ticket (2017 (!)) about the certificates not being > updated after metadata change. The ticket has a note that I was > unable > to reproduce it despite of several tries. > > The situation with multiple certificates of an IdP should work - it > is > supported. I.e. if IdP metadata advertises more then one > certificate, > then Unity should accept all of them. This feature is I think less > tested so I can suspect that there may some bug in it. > > I can add more detailed logging what I'll do for the next revision - > it > should help to track down the problem. We have also pending ticket to > be > able to see in details the runtime (effective) list of trusted IdPs > for > a SAML authenticator - but that's a bit bigger work, not planned in > near > term. > > > Is it possible that unity supports this common rollover mechanism > > for > > its own certificates in future? > Yes, why not. We can add a new option to IdP configuration, "former > credential" which would be used for metadata only. Sounds rather > easy. > Do you consider this also for SP (i.e. Unity SAML authenticator)? Yes it would be also effect the SP. I guess, if unity is used as Proxy, in most cases the same certificate is used for IdP and SP part. And you need to do the rollover in the same way for both. Cheers, Sander > > Best, > Krzysztof > -- Federated Systems and Data Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ---------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Volker Rieke Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Krzysztof B. <kb...@un...> - 2020-09-20 08:31:46
|
Dear Subscribers,
We are happy to announce general availability of a subsequent Unity
release. The version 3.3.3 brings four improvements. The most notable
ones are:
* complete group control over the REST API
* fixed handling of multiple SAML entity certificates loaded from SAML
metadata.
More details as always in Downloads <https://www.unity-idm.eu/downloads/>
Best regards,
Krzysztof
|
|
From: Krzysztof B. <kb...@un...> - 2020-09-17 10:28:48
|
Sander, W dniu 16.09.2020 o 12:35, Krzysztof Benedyczak pisze: > Hello Sander, > > W dniu 15.09.2020 o 09:55, Sander Apweiler pisze: >> Hello Krzysztof, >> I have some further information about this issue. The KIT IdP, who >> renews its certificate, offers at the moment two signing certificates >> in the federation metadata. The old one and the new one. This is a >> common way for the certificate renewal [1]. It seems that unity only >> supports one of them and this creates the mismatch. Unity should >> support all certificates which are provided via the IdP metadata. Good (well, somewhat) news here: indeed you are right - we have a bug here, in general related to handling multiple certificates per an entity. It is broken in a case when multiple certificates advertised for an entity share the same DN (what is actually the common case :/). Working on a fix. Best Krzysztof |
|
From: Krzysztof B. <kb...@un...> - 2020-09-16 10:36:14
|
Hello Sander, W dniu 15.09.2020 o 09:55, Sander Apweiler pisze: > Hello Krzysztof, > I have some further information about this issue. The KIT IdP, who > renews its certificate, offers at the moment two signing certificates > in the federation metadata. The old one and the new one. This is a > common way for the certificate renewal [1]. It seems that unity only > supports one of them and this creates the mismatch. Unity should > support all certificates which are provided via the IdP metadata. > > This rollover procedure should avoid outages for the users during the > update procedure. Especially when you use federations it took time > until the information reaches the other end of the chain. In best case > only a few minutes, when the information reaches the next level before > the level above fetches the information. In bad case it takes several > days, if the new information only fetched once per day. We have an old ticket (2017 (!)) about the certificates not being updated after metadata change. The ticket has a note that I was unable to reproduce it despite of several tries. The situation with multiple certificates of an IdP should work - it is supported. I.e. if IdP metadata advertises more then one certificate, then Unity should accept all of them. This feature is I think less tested so I can suspect that there may some bug in it. I can add more detailed logging what I'll do for the next revision - it should help to track down the problem. We have also pending ticket to be able to see in details the runtime (effective) list of trusted IdPs for a SAML authenticator - but that's a bit bigger work, not planned in near term. > Is it possible that unity supports this common rollover mechanism for > its own certificates in future? Yes, why not. We can add a new option to IdP configuration, "former credential" which would be used for metadata only. Sounds rather easy. Do you consider this also for SP (i.e. Unity SAML authenticator)? Best, Krzysztof |
|
From: Sander A. <sa....@fz...> - 2020-09-15 07:56:19
|
Hello Krzysztof, I have some further information about this issue. The KIT IdP, who renews its certificate, offers at the moment two signing certificates in the federation metadata. The old one and the new one. This is a common way for the certificate renewal [1]. It seems that unity only supports one of them and this creates the mismatch. Unity should support all certificates which are provided via the IdP metadata. This rollover procedure should avoid outages for the users during the update procedure. Especially when you use federations it took time until the information reaches the other end of the chain. In best case only a few minutes, when the information reaches the next level before the level above fetches the information. In bad case it takes several days, if the new information only fetched once per day. Is it possible that unity supports this common rollover mechanism for its own certificates in future? Cheers, Sander [1]: https://www.switch.ch/aai/guides/sp/certificate-rollover/ On Mon, 2020-09-14 at 07:35 +0200, Sander Apweiler wrote: > Hello Krzysztof, > I encountered an old problem, which is still present in unity. If an > IdP updated its certificate and provides it within the federation > metadata, like eduGAIN, unity does not update the used certificate by > the regular metadata update (once per hour). After the IdP changes > its > certificate unity just give the attached error. > > Last metadata update before the error: > 2020-09-11T09:40:46,282 [pool-2-thread-2] DEBUG > unity.server.saml.MetaToSPConfigConverter: Added a trusted IdP loaded > from SAML metadata: https://idp.scc.kit.edu/idp/shibboleth with > urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect binding > 2020-09-11T09:40:46,282 [pool-2-thread-2] DEBUG > unity.server.saml.MetaToSPConfigConverter: Added a trusted IdP loaded > from SAML metadata: https://idp.scc.kit.edu/idp/shibboleth with > urn:oasis:names:tc:SAML:2.0:bindings:SOAP binding > 2020-09-11T09:41:37,769 [pool-2-thread-2] DEBUG > unity.server.saml.MetaToSPConfigConverter: Added a trusted IdP loaded > from SAML metadata: https://idp.scc.kit.edu/idp/shibboleth with > urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect binding > 2020-09-11T09:41:37,769 [pool-2-thread-2] DEBUG > unity.server.saml.MetaToSPConfigConverter: Added a trusted IdP loaded > from SAML metadata: https://idp.scc.kit.edu/idp/shibboleth with > urn:oasis:names:tc:SAML:2.0:bindings:SOAP binding > > Using federations like DFN or eduGAIN makes it impossible to know > when > a certificate is updated. > > 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-09-14 05:35:44
|
Hello Krzysztof, I encountered an old problem, which is still present in unity. If an IdP updated its certificate and provides it within the federation metadata, like eduGAIN, unity does not update the used certificate by the regular metadata update (once per hour). After the IdP changes its certificate unity just give the attached error. Last metadata update before the error: 2020-09-11T09:40:46,282 [pool-2-thread-2] DEBUG unity.server.saml.MetaToSPConfigConverter: Added a trusted IdP loaded from SAML metadata: https://idp.scc.kit.edu/idp/shibboleth with urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect binding 2020-09-11T09:40:46,282 [pool-2-thread-2] DEBUG unity.server.saml.MetaToSPConfigConverter: Added a trusted IdP loaded from SAML metadata: https://idp.scc.kit.edu/idp/shibboleth with urn:oasis:names:tc:SAML:2.0:bindings:SOAP binding 2020-09-11T09:41:37,769 [pool-2-thread-2] DEBUG unity.server.saml.MetaToSPConfigConverter: Added a trusted IdP loaded from SAML metadata: https://idp.scc.kit.edu/idp/shibboleth with urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect binding 2020-09-11T09:41:37,769 [pool-2-thread-2] DEBUG unity.server.saml.MetaToSPConfigConverter: Added a trusted IdP loaded from SAML metadata: https://idp.scc.kit.edu/idp/shibboleth with urn:oasis:names:tc:SAML:2.0:bindings:SOAP binding Using federations like DFN or eduGAIN makes it impossible to know when a certificate is updated. 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-09-03 08:05:02
|
Dear Krzysztof, On Fri, 2020-08-28 at 19:39 +0200, Krzysztof Benedyczak wrote: > Dear Sander, > > W dniu 27.08.2020 o 10:09, Sander Apweiler pisze: > > Dear Krzysztof, > > I try to explain it. We start with one group, let's call them HIP. > > Within this group several projects are funded and the projects have > > different lifetimes and different resources. The people who are > > working > > in the projects are very volatile, that there is an ongoing adding > > and > > removing users from the projects. The projects are subgroups in > > unity. > > > > So the idea is to have a HIP-manager who creates the subgroups > > (projects in HIP) within the HIP group. The information about the > > funded projects, e.g. lifetime, or PI, is only known within the HIP > > group for this reason the handling of the subgroups should be > > handled > > to the HIP-group. Because the HIP-manager is not involved in the > > daily > > project work and membership updates are delayed if the HIP-manager > > needs to update it, the plan is to have project-managers that do > > the > > membership-management in their own projects (unity subgroups). > > Because > > different resources are bounded to (sub-)group membership we want > > to > > prohibit the manipulation of other subgroups where the project- > > manager > > is not member or the parent group we want to have the hierarchical > > administration permission. The GDPR is another issue why project- > > managers should not have access to the full tree. > > > > The process of creating and deleting projects within HIP (subgroups > > in > > unity) is ongoing. For this reason we can't do an initial > > delegation to > > HIP to create the subgroups, revoke revoke the delegation after it > > and > > delegate the subgroup management. > > > > The HIP-group is only one, we will have multiple of such groups. > > The > > manual subgroup creation and delegation creation does not scale > > very > > well for the unity administrators. The fast increasing number of > > registration and enquiry forms is another issue. If unity can > > handle > > this can be estimated by you much better. > > > > Hopefully this explains why the suggestion to delegate the > > subgroups > > does not fit for our use case. > > Thanks for the explanation, I guess I understand where this problem > is. > Let me ask one follow on question, to confirm my understanding. > > So let's imagine that the main unity admin created HIP and delegated > its > management to some HIP-wide admin. > > Now the HIP admin will add/remove projects under HIP from upman what > works fine. Let's say the projects under HIP are 'hop' and 'clap'. > > HIP admin wants to delegate hop and clap management to other ppl. But > it > can be done only by the main Unity admin what is cumbersome and is > the > problem described here. > > Did I get this correctly? Yes. The "administrator" of hop and clap should invite the collaborators of their projects. > > > If yes then I, yes we have a feature gap here. We would need > something > like this: > > 1. extra permission (settable by the main unity admin on projects > admin): allow-to-re-delegate-subgroups > > 2. in upman (only for ppl with the permission from the point above) > add > option to delegate subgroup management separately (as a sub project). > > 3. in upman allow to control sub-project admins (what is separate > from > the main project admin) > > 4. internally we would need to take care of deriving all forms for > the > sub project from the main project forms > > That isn't a small change, but also doesn't sounds as something > terribly > complicated. This sounds like the feature we need. Can you send me an estimation? Cheers, Sander > > > Best > Krzysztof > > -- Federated Systems and Data Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ---------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Volker Rieke Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Krzysztof B. <kb...@un...> - 2020-08-28 17:39:34
|
Dear Sander, W dniu 27.08.2020 o 10:09, Sander Apweiler pisze: > Dear Krzysztof, > I try to explain it. We start with one group, let's call them HIP. > Within this group several projects are funded and the projects have > different lifetimes and different resources. The people who are working > in the projects are very volatile, that there is an ongoing adding and > removing users from the projects. The projects are subgroups in unity. > > So the idea is to have a HIP-manager who creates the subgroups > (projects in HIP) within the HIP group. The information about the > funded projects, e.g. lifetime, or PI, is only known within the HIP > group for this reason the handling of the subgroups should be handled > to the HIP-group. Because the HIP-manager is not involved in the daily > project work and membership updates are delayed if the HIP-manager > needs to update it, the plan is to have project-managers that do the > membership-management in their own projects (unity subgroups). Because > different resources are bounded to (sub-)group membership we want to > prohibit the manipulation of other subgroups where the project-manager > is not member or the parent group we want to have the hierarchical > administration permission. The GDPR is another issue why project- > managers should not have access to the full tree. > > The process of creating and deleting projects within HIP (subgroups in > unity) is ongoing. For this reason we can't do an initial delegation to > HIP to create the subgroups, revoke revoke the delegation after it and > delegate the subgroup management. > > The HIP-group is only one, we will have multiple of such groups. The > manual subgroup creation and delegation creation does not scale very > well for the unity administrators. The fast increasing number of > registration and enquiry forms is another issue. If unity can handle > this can be estimated by you much better. > > Hopefully this explains why the suggestion to delegate the subgroups > does not fit for our use case. Thanks for the explanation, I guess I understand where this problem is. Let me ask one follow on question, to confirm my understanding. So let's imagine that the main unity admin created HIP and delegated its management to some HIP-wide admin. Now the HIP admin will add/remove projects under HIP from upman what works fine. Let's say the projects under HIP are 'hop' and 'clap'. HIP admin wants to delegate hop and clap management to other ppl. But it can be done only by the main Unity admin what is cumbersome and is the problem described here. Did I get this correctly? If yes then I, yes we have a feature gap here. We would need something like this: 1. extra permission (settable by the main unity admin on projects admin): allow-to-re-delegate-subgroups 2. in upman (only for ppl with the permission from the point above) add option to delegate subgroup management separately (as a sub project). 3. in upman allow to control sub-project admins (what is separate from the main project admin) 4. internally we would need to take care of deriving all forms for the sub project from the main project forms That isn't a small change, but also doesn't sounds as something terribly complicated. Best Krzysztof |
|
From: Krzysztof B. <kb...@un...> - 2020-08-28 16:35:32
|
Sander, W dniu 25.08.2020 o 07:53, Sander Apweiler pisze: > 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? Reproduced, will be fixed in next revision. Thanks, Krzysztof |
|
From: Sander A. <sa....@fz...> - 2020-08-27 08:09:39
|
Dear Krzysztof, I try to explain it. We start with one group, let's call them HIP. Within this group several projects are funded and the projects have different lifetimes and different resources. The people who are working in the projects are very volatile, that there is an ongoing adding and removing users from the projects. The projects are subgroups in unity. So the idea is to have a HIP-manager who creates the subgroups (projects in HIP) within the HIP group. The information about the funded projects, e.g. lifetime, or PI, is only known within the HIP group for this reason the handling of the subgroups should be handled to the HIP-group. Because the HIP-manager is not involved in the daily project work and membership updates are delayed if the HIP-manager needs to update it, the plan is to have project-managers that do the membership-management in their own projects (unity subgroups). Because different resources are bounded to (sub-)group membership we want to prohibit the manipulation of other subgroups where the project-manager is not member or the parent group we want to have the hierarchical administration permission. The GDPR is another issue why project- managers should not have access to the full tree. The process of creating and deleting projects within HIP (subgroups in unity) is ongoing. For this reason we can't do an initial delegation to HIP to create the subgroups, revoke revoke the delegation after it and delegate the subgroup management. The HIP-group is only one, we will have multiple of such groups. The manual subgroup creation and delegation creation does not scale very well for the unity administrators. The fast increasing number of registration and enquiry forms is another issue. If unity can handle this can be estimated by you much better. Hopefully this explains why the suggestion to delegate the subgroups does not fit for our use case. Cheers, Sander On Mon, 2020-08-24 at 09:58 +0200, Krzysztof Benedyczak wrote: > 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 > -- 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 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 >> |
