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: Marcus H. <ha...@ki...> - 2020-10-06 09:46:18
|
On 10/06/20 11:32, Krzysztof Benedyczak wrote: > W dniu 06.10.2020 o 09:32, Marcus Hardt pisze: > > On 10/06/20 09:24, Krzysztof Benedyczak wrote: > > > Marcus, > > > > > > W dniu 05.10.2020 o 10:47, Marcus Hardt pisze: > > > > > The fact that the user gets a cookie > > > > > from a site which was not visited is just few bytes on her hard drive, > > > > > nothing more. So I can ask: what is the real problem here? > > > > By requesting the picture, the user informs _all_ IdPs that he is about to > > > > log in to unity. That does not seem right, does it? > > > No, that's not true. The IdPs can only know that some *anonymous* one is > > > trying to enter unity instance (and only after if and after they check that > > > referer URL is of some unity instance). Nothing more. > > The anonymous is the goal here. For this unity needs to proxy the > > requests. At the moments it's my browser requesting those images. This is > > by no means anonymous. > > Are you browsing the web? Entering _any_ page opens a huge risk that this > webpage has an asset embedded and your browser will download it. What's more > in the age of CDNs you are sharing your "data" with them almost always. Not > to mention cloudflare and other similar services. I know. Personally, I'm using uMatrix to get rid of that stuff. Plus I'm supporting initatives like noyb.eu to help enforcing the existing legislation against this. But this is not about me. This is about Data Privacy Officers in the Public Sector. The one of FZJ is apparently rather tolerant. I hear people at KIT that claim their service had to be deactivated until fixed for such reasons. For HIFIS and HDF we cannot risk that. M. > > > What privacy concern is there? > > I am unneccessarily forced to releasing information to third parties, > > potentially outside europe, that I've never wanted to authorise. > > Well, what information? That some unknown person using say Firefox entered a > webpage Y from IP Z. > > If you are very concerned about Z use one of public VPN services (I do - > solves the problem for all cases). Still Z is mostly useless information in > age of NAT and dynamic IPs. > > You can also fake client agent (pretend that you are curl) if this matters > for you - but why? > > If your concern is about tracking for advertising/marketing - disable 3rd > party cookies in your browser. But seriously: are edugain IdPs providing > contextual ads around the globe? :-) > > Best, > Krzysztof > -- Marcus. |
|
From: Krzysztof B. <kb...@un...> - 2020-10-06 09:32:30
|
W dniu 06.10.2020 o 09:32, Marcus Hardt pisze: > On 10/06/20 09:24, Krzysztof Benedyczak wrote: >> Marcus, >> >> W dniu 05.10.2020 o 10:47, Marcus Hardt pisze: >>>> The fact that the user gets a cookie >>>> from a site which was not visited is just few bytes on her hard drive, >>>> nothing more. So I can ask: what is the real problem here? >>> By requesting the picture, the user informs _all_ IdPs that he is about to >>> log in to unity. That does not seem right, does it? >> No, that's not true. The IdPs can only know that some *anonymous* one is >> trying to enter unity instance (and only after if and after they check that >> referer URL is of some unity instance). Nothing more. > The anonymous is the goal here. For this unity needs to proxy the > requests. At the moments it's my browser requesting those images. This is > by no means anonymous. Are you browsing the web? Entering _any_ page opens a huge risk that this webpage has an asset embedded and your browser will download it. What's more in the age of CDNs you are sharing your "data" with them almost always. Not to mention cloudflare and other similar services. >> What privacy concern is there? > I am unneccessarily forced to releasing information to third parties, > potentially outside europe, that I've never wanted to authorise. Well, what information? That some unknown person using say Firefox entered a webpage Y from IP Z. If you are very concerned about Z use one of public VPN services (I do - solves the problem for all cases). Still Z is mostly useless information in age of NAT and dynamic IPs. You can also fake client agent (pretend that you are curl) if this matters for you - but why? If your concern is about tracking for advertising/marketing - disable 3rd party cookies in your browser. But seriously: are edugain IdPs providing contextual ads around the globe? :-) Best, Krzysztof |
|
From: Marcus H. <ha...@ki...> - 2020-10-06 07:32:58
|
On 10/06/20 09:24, Krzysztof Benedyczak wrote: > Marcus, > > W dniu 05.10.2020 o 10:47, Marcus Hardt pisze: > > > The fact that the user gets a cookie > > > from a site which was not visited is just few bytes on her hard drive, > > > nothing more. So I can ask: what is the real problem here? > > By requesting the picture, the user informs _all_ IdPs that he is about to > > log in to unity. That does not seem right, does it? > > No, that's not true. The IdPs can only know that some *anonymous* one is > trying to enter unity instance (and only after if and after they check that > referer URL is of some unity instance). Nothing more. The anonymous is the goal here. For this unity needs to proxy the requests. At the moments it's my browser requesting those images. This is by no means anonymous. > What privacy concern is there? I am unneccessarily forced to releasing information to third parties, potentially outside europe, that I've never wanted to authorise. > > Plus, some (very few) are configured to offer certificate authentication, > > if an appropriate certificate is in the browser. The browser shows a popup > > for the user to choose. So, when I want to choose KIT on unity, some other > > site asks for the certificate? Fortunately, not _all_ IdPs are queried > > (as did another project in an early version). > > That is obvious misconfiguration of your IdP sites. Not at all. It's any IdP that is in the metadata. We have no control about them. > They should not require > authN for public assets like a logo advertised in metadata for > authentication purposes. Absolutely agreed. > I can see the value in the request to cache the images by unity - but that's > more of an optimization, not a privacy issue. -- Marcus. |
|
From: Krzysztof B. <kb...@un...> - 2020-10-06 07:24:30
|
Marcus, W dniu 05.10.2020 o 10:47, Marcus Hardt pisze: >> The fact that the user gets a cookie >> from a site which was not visited is just few bytes on her hard drive, >> nothing more. So I can ask: what is the real problem here? > By requesting the picture, the user informs _all_ IdPs that he is about to > log in to unity. That does not seem right, does it? No, that's not true. The IdPs can only know that some *anonymous* one is trying to enter unity instance (and only after if and after they check that referer URL is of some unity instance). Nothing more. What privacy concern is there? > Plus, some (very few) are configured to offer certificate authentication, > if an appropriate certificate is in the browser. The browser shows a popup > for the user to choose. So, when I want to choose KIT on unity, some other > site asks for the certificate? Fortunately, not _all_ IdPs are queried > (as did another project in an early version). That is obvious misconfiguration of your IdP sites. They should not require authN for public assets like a logo advertised in metadata for authentication purposes. I can see the value in the request to cache the images by unity - but that's more of an optimization, not a privacy issue. Best, Krzysztof |
|
From: Marcus H. <ha...@ki...> - 2020-10-05 09:12:00
|
On 10/02/20 11:54, Krzysztof Benedyczak wrote: > Hi Sander, > > W dniu 02.10.2020 o 11:17, Sander Apweiler pisze: > > Hi Krzysztof, > > > > On Fri, 2020-10-02 at 11:13 +0200, Krzysztof Benedyczak wrote: > > > Hi Sander, > > > > > > W dniu 02.10.2020 o 10:54, Sander Apweiler pisze: > > > > Good Morning Krzysztof, > > > > > > > > we got a lot of feedback of 3rd site content and cookies triggered > > > > by > > > > unity. This content is are the logos and cookies of the remote IdPs > > > > (from eduGAIN). The users never visited these IdPs. The users are > > > > very > > > > unhappy with this behaviour. Can this be changed, that unity > > > > fetches > > > > the logos, caches them and provide them with the login screen? > > > > > > > Do you mean that the process of showing SAML federation logos (which > > > are > > > provided as links in federation metadata) should not happen lazy > > > when > > > user enters the authentication page, but rather be done in > > > background, > > > from time to time, so that all logos are served from Unity server > > > itself? > > Exactly. I guess when the logos are served from unity instead of the > > IdPs, the cookie issue is solved, too. > > Yes - we can change the behavior, I've opened a ticket. This will be a > rather complex process (this is lot's of data which would need to be > downloaded, stored and refreshed) - rather a bigger change, so hard to say > when we schedule it. > > On the other hand, users are constantly tracked by FB, Google, and ton of > other sites with real consequences. Yes, and in addition to google and facebook, nyob has started to sue 101 companies in europe that do the same thing [1]. > The fact that the user gets a cookie > from a site which was not visited is just few bytes on her hard drive, > nothing more. So I can ask: what is the real problem here? By requesting the picture, the user informs _all_ IdPs that he is about to log in to unity. That does not seem right, does it? Plus, some (very few) are configured to offer certificate authentication, if an appropriate certificate is in the browser. The browser shows a popup for the user to choose. So, when I want to choose KIT on unity, some other site asks for the certificate? Fortunately, not _all_ IdPs are queried (as did another project in an early version). [1] https://noyb.eu/en/update-noybs-101-complaints-eu-us-data-transfers -- Marcus. |
|
From: Krzysztof B. <kb...@un...> - 2020-10-02 09:55:04
|
Hi Sander, W dniu 02.10.2020 o 11:17, Sander Apweiler pisze: > Hi Krzysztof, > > On Fri, 2020-10-02 at 11:13 +0200, Krzysztof Benedyczak wrote: >> Hi Sander, >> >> W dniu 02.10.2020 o 10:54, Sander Apweiler pisze: >>> Good Morning Krzysztof, >>> >>> we got a lot of feedback of 3rd site content and cookies triggered >>> by >>> unity. This content is are the logos and cookies of the remote IdPs >>> (from eduGAIN). The users never visited these IdPs. The users are >>> very >>> unhappy with this behaviour. Can this be changed, that unity >>> fetches >>> the logos, caches them and provide them with the login screen? >>> >> Do you mean that the process of showing SAML federation logos (which >> are >> provided as links in federation metadata) should not happen lazy >> when >> user enters the authentication page, but rather be done in >> background, >> from time to time, so that all logos are served from Unity server >> itself? > Exactly. I guess when the logos are served from unity instead of the > IdPs, the cookie issue is solved, too. Yes - we can change the behavior, I've opened a ticket. This will be a rather complex process (this is lot's of data which would need to be downloaded, stored and refreshed) - rather a bigger change, so hard to say when we schedule it. On the other hand, users are constantly tracked by FB, Google, and ton of other sites with real consequences. The fact that the user gets a cookie from a site which was not visited is just few bytes on her hard drive, nothing more. So I can ask: what is the real problem here? Cheers, Krzysztof |
|
From: Sander A. <sa....@fz...> - 2020-10-02 09:18:07
|
Hi Krzysztof, On Fri, 2020-10-02 at 11:13 +0200, Krzysztof Benedyczak wrote: > Hi Sander, > > W dniu 02.10.2020 o 10:54, Sander Apweiler pisze: > > Good Morning Krzysztof, > > > > we got a lot of feedback of 3rd site content and cookies triggered > > by > > unity. This content is are the logos and cookies of the remote IdPs > > (from eduGAIN). The users never visited these IdPs. The users are > > very > > unhappy with this behaviour. Can this be changed, that unity > > fetches > > the logos, caches them and provide them with the login screen? > > > Do you mean that the process of showing SAML federation logos (which > are > provided as links in federation metadata) should not happen lazy > when > user enters the authentication page, but rather be done in > background, > from time to time, so that all logos are served from Unity server > itself? Exactly. I guess when the logos are served from unity instead of the IdPs, the cookie issue is solved, too. Cheers, Sander > > Cheers > Krzysztof > -- Federated Systems and Data Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ---------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Volker Rieke Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Krzysztof B. <kb...@un...> - 2020-10-02 09:13:40
|
Hi Sander, W dniu 02.10.2020 o 10:54, Sander Apweiler pisze: > Good Morning Krzysztof, > > we got a lot of feedback of 3rd site content and cookies triggered by > unity. This content is are the logos and cookies of the remote IdPs > (from eduGAIN). The users never visited these IdPs. The users are very > unhappy with this behaviour. Can this be changed, that unity fetches > the logos, caches them and provide them with the login screen? > Do you mean that the process of showing SAML federation logos (which are provided as links in federation metadata) should not happen lazy when user enters the authentication page, but rather be done in background, from time to time, so that all logos are served from Unity server itself? Cheers Krzysztof |
|
From: Sander A. <sa....@fz...> - 2020-10-02 08:54:53
|
Good Morning Krzysztof, we got a lot of feedback of 3rd site content and cookies triggered by unity. This content is are the logos and cookies of the remote IdPs (from eduGAIN). The users never visited these IdPs. The users are very unhappy with this behaviour. Can this be changed, that unity fetches the logos, caches them and provide them with the login screen? Best regards, Sander -- Federated Systems and Data Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ---------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Volker Rieke Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Krzysztof B. <kb...@un...> - 2020-09-24 11:32:11
|
W dniu 24.09.2020 o 13:25, Sander Apweiler pisze: > Dear Krzysztof, > thanks for the feedback. When we started with our first unity, it did > not work behind a reverse proxy. I'll give it a new try, when I find > some time. Note that there are options in Unity config file to configure it properly. |
|
From: Sander A. <sa....@fz...> - 2020-09-24 11:25:47
|
Dear Krzysztof, thanks for the feedback. When we started with our first unity, it did not work behind a reverse proxy. I'll give it a new try, when I find some time. Cheers, Sander On Thu, 2020-09-24 at 13:13 +0200, Krzysztof Benedyczak wrote: > Dear Sander, > > W dniu 23.09.2020 o 14:09, Sander Apweiler pisze: > > Dear Krzysztof, > > > > we switched in one of our instances the domain this summer. All > > connected services already use the new domain, but users still > > found > > the old domain and got a certificate mismatch warning from the > > browser. > > Because the different domains are owned by different centres, we > > can't > > use a certificate containing both domains. > > > > Is it possible to use two certificates and domain names in unity > > for > > the webserver part? SAML and OAuth should be still handled with one > > domain/entity ID. Separating webserver certificates from SAML/OAuth > > should be possible with different credential definitions. > > Technically it is possible. The feature you are asking for is SNI > extension of the TLS protocol. It is supported by Jetty and Java > which > Unity is using but Unity currently doesn't offer a way to setup > Jetty > with multiple credentials. > > We can have it implemented, however I can point you out to an > alternative solution: you can expose Unity behind a (reverse) proxy > server, like Apache. Unity supports it pretty well, we use it in > production often. Then you get access to all features of the Apache > (or > other) server, where you can setup for instance SNI. > > 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-09-24 11:14:13
|
Dear Sander, W dniu 23.09.2020 o 14:09, Sander Apweiler pisze: > Dear Krzysztof, > > we switched in one of our instances the domain this summer. All > connected services already use the new domain, but users still found > the old domain and got a certificate mismatch warning from the browser. > Because the different domains are owned by different centres, we can't > use a certificate containing both domains. > > Is it possible to use two certificates and domain names in unity for > the webserver part? SAML and OAuth should be still handled with one > domain/entity ID. Separating webserver certificates from SAML/OAuth > should be possible with different credential definitions. Technically it is possible. The feature you are asking for is SNI extension of the TLS protocol. It is supported by Jetty and Java which Unity is using but Unity currently doesn't offer a way to setup Jetty with multiple credentials. We can have it implemented, however I can point you out to an alternative solution: you can expose Unity behind a (reverse) proxy server, like Apache. Unity supports it pretty well, we use it in production often. Then you get access to all features of the Apache (or other) server, where you can setup for instance SNI. HTH Krzysztof |
|
From: Sander A. <sa....@fz...> - 2020-09-23 12:10:23
|
Dear Krzysztof, we switched in one of our instances the domain this summer. All connected services already use the new domain, but users still found the old domain and got a certificate mismatch warning from the browser. Because the different domains are owned by different centres, we can't use a certificate containing both domains. Is it possible to use two certificates and domain names in unity for the webserver part? SAML and OAuth should be still handled with one domain/entity ID. Separating webserver certificates from SAML/OAuth should be possible with different credential definitions. 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-23 07:35:04
|
Hello Krzysztof, we have an issue with the invitation of already existing users via upman. If the invited user clicks on the link, unity gets a null pointer exception (see the attached log). We used the automatically created enquiry and only added a mandatory form opt-in. Do you have an idea about this null pointer? 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-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 ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
