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: Sander A. <sa....@fz...> - 2020-12-08 11:47:57
|
Hi Krzysztof, we get DB Exceptions about Error updating database. Cause: java.sql.SQLSyntaxErrorException: (conn=296180) Data too long for column 'NAME' at row 1 ### The error may exist in pl/edu/icm/unity/store/rdbms/mapper/Tokens.xml Sadly Maria log is empty. Is there a possibility to increase the log level on unity site? We are using 2048 bit certificate key to sign tokens. 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-12-07 10:49:19
|
Dear Sander, W dniu 02.12.2020 o 08:24, Sander Apweiler pisze: > Dear Krzysztof, > > We have a small improvement for invitation templates. We as unity > administrators, not as group administrators got a lot of replies, to > which group the users was invited. Of course we can modify the template > but we don't have access to the group name. Could you create a variable > containing the group displayname, like it already exists for the > registration form or expiration date? Well, perhaps yes, but that's not that obvious feature. The thing is that invitation (as well as its form) can include more then a single group. Actually there may be multiple group parameters in form AND some of them may be multivalued. Consider the attached screenshot. So we would need to add at a minimum the following variables to the invitation message template: ${prefilledAttribute['attrName']} ${prefilledIdentity['idName']} ${prefilledGroup['groupsSpec']} One problem is that we don't have yet any support for parametrized variables in message templates - we would need to introduce sth like this. Other problem is that the above may still not work in your case (?) - if invitation contains multiple groups then you most likely want to show only a specific one (e.g. in the screenshot it would be /A/B/C (or its name))? Cheers, Krzysztof |
From: Sander A. <sa....@fz...> - 2020-12-02 07:25:01
|
Dear Krzysztof, We have a small improvement for invitation templates. We as unity administrators, not as group administrators got a lot of replies, to which group the users was invited. Of course we can modify the template but we don't have access to the group name. Could you create a variable containing the group displayname, like it already exists for the registration form or expiration date? 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-12-01 13:17:07
|
Hi Krzysztof, thank you very much! Cheers, Sander On Tue, 2020-12-01 at 13:37 +0100, Krzysztof Benedyczak wrote: > Hi Sander, > > W dniu 01.12.2020 o 08:26, Sander Apweiler pisze: > > Dear Krzysztof, > > > > we have connected our instance to an OIDC IdP. This IdP releases > > email > > and email_verified attributes. Currently we map only the email: > > > > Condition: true > > Action: mapAttribute > > Action parameters: > > unityAttribute = email > > group = / > > expression = attr['email'] > > effect = CREATE_OR_UPDATE > > > > Can we "map" the email_verified information too? We want to skip > > the > > verification in case this is already done by the IdP. The condition > > part is no problem, but how can we set the information to email > > attribute? > > Sure, you can. See > https://www.unity-idm.eu/documentation/unity-3.4.0/manual.html#_e_mail_confirmations > , > section 7.4.4 precisely. You would need to add the "[CONFIRMED]" > suffix > basing on the email_verified attribute, sth. like > > attr['email'] + (attr['email_verified'] == 'true' ? '[CONFIRMED]' : > '') > > - you should be able to fine tune that depending on types, whether > this > email_verified is always present or optional etc. > > > 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-12-01 12:37:53
|
Hi Sander, W dniu 01.12.2020 o 08:26, Sander Apweiler pisze: > Dear Krzysztof, > > we have connected our instance to an OIDC IdP. This IdP releases email > and email_verified attributes. Currently we map only the email: > > Condition: true > Action: mapAttribute > Action parameters: > unityAttribute = email > group = / > expression = attr['email'] > effect = CREATE_OR_UPDATE > > Can we "map" the email_verified information too? We want to skip the > verification in case this is already done by the IdP. The condition > part is no problem, but how can we set the information to email > attribute? Sure, you can. See https://www.unity-idm.eu/documentation/unity-3.4.0/manual.html#_e_mail_confirmations, section 7.4.4 precisely. You would need to add the "[CONFIRMED]" suffix basing on the email_verified attribute, sth. like attr['email'] + (attr['email_verified'] == 'true' ? '[CONFIRMED]' : '') - you should be able to fine tune that depending on types, whether this email_verified is always present or optional etc. Cheers, Krzysztof |
From: Sander A. <sa....@fz...> - 2020-12-01 07:27:04
|
Dear Krzysztof, we have connected our instance to an OIDC IdP. This IdP releases email and email_verified attributes. Currently we map only the email: Condition: true Action: mapAttribute Action parameters: unityAttribute = email group = / expression = attr['email'] effect = CREATE_OR_UPDATE Can we "map" the email_verified information too? We want to skip the verification in case this is already done by the IdP. The condition part is no problem, but how can we set the information to email attribute? Cheers, Sander -- Federated Systems and Data Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ---------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Volker Rieke Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
From: Krzysztof B. <kb...@un...> - 2020-11-26 10:07:16
|
Dear Subscribers, Unity 3.4.0 was just released and brings couple of significant new features. FIDO/WebAuthn support Finally Unity offers support for hardware tokens based authentication. And more, as the support is based on the FIDO standard, so all compatible devices and even software like Android OS or Windows Hello can be used for authentication. Refreshed consent screen Consent screen was significantly reworked. Technical language was removed, information is end-user oriented, unnecessary data was dropped to have cleaner presentation. To take full advantage of the new look and feel make sure to properly describe your OAuth scopes and set logos for the clients (note that OAuth clients logo now uses image attribute type, supporting variety of formats). Sub-projects support in UpMan UpMan UI was generally refreshed and aligned with theme of Console. Besides of that a new feature was added: Unity admin can allow selected project managers to create sub-projects on their own. This feature must be enabled on each project and additionally Unity offers new authorization role which needs to be assigned to authorized managers. Sub-projects can be managed with UpMan in the very same way as root projects created from Consloe. Also in Console all groups which are managed via UpMan are marked and can be easily identified in the group browser. Admin UI dropped As previously announced the legacy AdminUI was dropped in this release. Make sure to enable console before the update. jpegImage attribute syntax replaced by image syntax The deprecated jpegImage attribute syntax was dropped. All instances will be migrated during update to the image attribute syntax. This change allows for using PNG images (and GIFs) everywhere, as well as improves JPG images quality which was noticeably impacted by the jpegImage. More details and download links: https://www.unity-idm.eu/downloads/ Best regards, Krzysztof |
From: Krzysztof B. <kb...@un...> - 2020-11-11 11:19:20
|
Dear Sander, W dniu 10.11.2020 o 13:40, Sander Apweiler pisze: > Dear Krzysztof, > > in previous ecxhange with Marcus you said that the token length is > depending on the key length, used for signing. We do not want to change > our primary certificate/key because of the connection to federations. > We want to add a dedicated key for signing the OAuth tokens. As far as > I understood the PKI documentation unity can only handle credentials > with certificate and key. Is this correct or is there a possibility to > add only the key? I think there are two questions here. 1. "We do not want to change our primary certificate/key because of the connection to federations. We want to add a dedicated key for signing the OAuth tokens." -> this is of course possible. You can define as many PKI credentials (cert + private key) in Unity and use them for different purposes. E.g. you can add one extra and configure it just for OAuth JWT. 2. "I understood the PKI documentation unity can only handle credentials with certificate and key. Is this correct or is there a possibility to add only the key?" -> PKI is public key infrastructure. By definition keys in PKI are certificate+private key, there is no other option (assuming that we do use X.509 PKI, which we do; but also in other trust systems as GPG you also have public key + private key, only difference is that public key is not wrapped as a certificate). But, for OAuth JWT you still have two options. Either you can use PKI-based signature (i.e. based on public/private keys) or pre-shared-key based signatures. You control this in Oauth IdP config. Compare: vs: HTH, Krzysztof |
From: Sander A. <sa....@fz...> - 2020-11-10 12:41:39
|
Dear Krzysztof, in previous ecxhange with Marcus you said that the token length is depending on the key length, used for signing. We do not want to change our primary certificate/key because of the connection to federations. We want to add a dedicated key for signing the OAuth tokens. As far as I understood the PKI documentation unity can only handle credentials with certificate and key. Is this correct or is there a possibility to add only the key? 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-11-02 08:58:57
|
Hi Krzysztof, we encountered on all our instances sometimes "issues" with the login screens on all endpoints. The spinning wheel is displayed for 20 seconds +. I guess the grid is build/updated in this time. Of course having eduGain federation with 3000+ identity providers is a long list., but do you have a hint how we could improve this? Do you know if this issue is on unity (e.g. performance issue while rebuilding) or on the client site? 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-10-12 11:32:30
|
Dear Subscribers, Release 3.3.4 was published today. It brings couple of small improvements and bug fixes. Detailed list of changes is available on the Downloads <https://www.unity-idm.eu/downloads/> page. Important note for H2 DB users: we have found a problem introduced in the release 3.3.0 related to the upgraded H2 DB v1.4.200. It is not working in a stable way under a heavy load. In this revision we downgraded H2 to 1.4.199. Up to our tests this should not cause any issues, but making a text backup is strongly advised. Best regards, Krzysztof |
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 ----------------------------------------------------------------------- ----------------------------------------------------------------------- |