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
(28) |
Nov
(10) |
Dec
|
|
From: Krzysztof B. <kb...@un...> - 2024-11-15 10:00:31
|
Hi Sander, W dniu 7.11.2024 o 11:20, Sander Apweiler pisze: > Hi Krzysztof, > hi Roman, > > is there another reason why it is not possible to store the consent to > the released attributes beside of using a public client? We have some > confidential clients, where user can not store their consent and we do > not understand the reason for it. There are many possible reasons: * prompt = CONSENT requested by the OAuth client * added scope (consent was stored with some scopes, during new sign-in additional scopes are requested) * added audience also Unity UI will be shown when there is active value selection configured, enquiry pending or updated policies to be accepted. DEBUG logging on the oauth logger should provide some basic information. HTH, Krzysztof |
|
From: Sander A. <sa....@fz...> - 2024-11-13 10:48:53
|
Hello Roman, the logo in userhome endpoint is also not scaled correctly, while it is in the console endpoint. On Wed, 2024-11-13 at 11:14 +0100, Roman Krysiński wrote: > Good Morning Marvin, > > Thank you for pointing this out. We will look into this soon and let > you know. > > Best regards, > Roman > > pon., 11 lis 2024 o 09:59 Winkens, Marvin <m.w...@fz...> > napisał(a): > > > > > > > > > > > > > > > > > > > > Dear unity-mailing-list, > > > > > > when using chromium the icons of organisations on the login page > > are scaled differently to firefox. See attached images. > > > > unity-idm-version: 4.0.2 > > > > My guess is, that this is a bug with the new unity version and not > > a configuration issue. I can reproduce this on every endpoint with > > login. > > > > With best regards, > > Marvin Winkens > > > > > > > > ------------------------------------------------------------------- > > ------------------ > > ------------------------------------------------------------------- > > ------------------ > > Forschungszentrum Jülich GmbH > > 52425 Jülich > > Sitz der Gesellschaft: Jülich > > Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 > > Vorsitzender des Aufsichtsrats: MinDir Stefan Müller > > Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), > > Karsten Beneke (stellv. Vorsitzender), Dr. Ir. Pieter Jansens > > ------------------------------------------------------------------- > > ------------------ > > ------------------------------------------------------------------- > > ----------------- > > > > > > > > ------------------------------------------------------------------- > > ----------------------------- > > ------------------------------------------------------------------- > > ----------------------------- > > Forschungszentrum Jülich GmbH > > 52425 Jülich > > Sitz der Gesellschaft: Jülich > > Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 > > Vorsitzender des Aufsichtsrats: MinDir Stefan Müller > > Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), > > Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Ir. Pieter Jansens > > ------------------------------------------------------------------- > > ----------------------------- > > ------------------------------------------------------------------- > > ----------------------------- > > > > _______________________________________________ > > Unity-idm-discuss mailing list > > Uni...@li... > > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss > _______________________________________________ > Unity-idm-discuss mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss -- Large-Scale Data Science Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Ir. Pieter Jansens ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Roman K. <ro...@un...> - 2024-11-13 10:14:30
|
Good Morning Marvin, Thank you for pointing this out. We will look into this soon and let you know. Best regards, Roman pon., 11 lis 2024 o 09:59 Winkens, Marvin <m.w...@fz...> napisał(a): > > Dear unity-mailing-list, > > when using chromium the icons of organisations on the login page are > scaled differently to firefox. See attached images. > > > unity-idm-version: 4.0.2 > > > My guess is, that this is a bug with the new unity version and not a > configuration issue. I can reproduce this on every endpoint with login. > > > With best regards, > > Marvin Winkens > > ------------------------------------------------------------------------------------- > > ------------------------------------------------------------------------------------- > Forschungszentrum Jülich GmbH > 52425 Jülich > Sitz der Gesellschaft: Jülich > Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 > Vorsitzender des Aufsichtsrats: MinDir Stefan Müller > Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), > Karsten Beneke (stellv. Vorsitzender), Dr. Ir. Pieter Jansens > > ------------------------------------------------------------------------------------- > > ------------------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------------------------------ > > ------------------------------------------------------------------------------------------------ > Forschungszentrum Jülich GmbH > 52425 Jülich > Sitz der Gesellschaft: Jülich > Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 > Vorsitzender des Aufsichtsrats: MinDir Stefan Müller > Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), > Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Ir. Pieter Jansens > > ------------------------------------------------------------------------------------------------ > > ------------------------------------------------------------------------------------------------ > _______________________________________________ > Unity-idm-discuss mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss > |
|
From: Winkens, M. <m.w...@fz...> - 2024-11-11 08:59:00
|
Dear unity-mailing-list, when using chromium the icons of organisations on the login page are scaled differently to firefox. See attached images. unity-idm-version: 4.0.2 My guess is, that this is a bug with the new unity version and not a configuration issue. I can reproduce this on every endpoint with login. With best regards, Marvin Winkens ------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Karsten Beneke (stellv. Vorsitzender), Dr. Ir. Pieter Jansens ------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Ir. Pieter Jansens ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ |
|
From: Roman K. <ro...@un...> - 2024-11-08 10:54:55
|
Dear Subscribers, A new patch release 4.0.3 is now available. The following has been released: - *Support for key ID in JWT:* in the OpenID Connect (OIDC) flow, after exchanging an authorization code for an ID token, your OIDC clients can now validate the ID token and confirm that Unity-IdM is the signing authority. The OAuth /jwk public endpoint has been updated to expose the key IDs, and the key ID used to sign the JWT token is now included in the JWT token header. - *Fix for Console OAuth IdP editor:* When a user updates the OAuth IdP configuration and sets the “Token signing algorithm” to an ECC-based option with an invalid signing credential, submitting the configuration fails, causing the updated IdP configuration to be discarded. This patch addresses this issue. All relevant links are available here: https://unity-idm.eu/releases/release-4-0-3/ Best regards, Roman |
|
From: Sander A. <sa....@fz...> - 2024-11-07 10:20:20
|
Hi Krzysztof, hi Roman, is there another reason why it is not possible to store the consent to the released attributes beside of using a public client? We have some confidential clients, where user can not store their consent and we do not understand the reason for it. Best regards, Sander -- Large-Scale Data Science Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Ir. Pieter Jansens ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Roman K. <ro...@un...> - 2024-11-07 09:40:59
|
Hi Sander, Yes, the implementation is done, and currently this needs to go through the QA cycle. If nothing unexpected happens, then we can expect patch release tomorrow or early next week. Best regards, Roman czw., 7 lis 2024 o 10:08 Sander Apweiler <sa....@fz...> napisał(a): > Dear Roman, > do you have an estimation for the release of the patch? > > Best regards, > Sander > > On Tue, 2024-10-29 at 12:43 +0100, Roman Krysiński wrote: > > Good morning Sander, > > > > OK, we will work on it soon and release it in the 4.0.3 patch. > > > > Best regards, > > Roman > > > > > > wt., 29 paź 2024 o 10:53 Sander Apweiler <sa....@fz...> > > napisał(a): > > > Good morning Krzysztof, > > > this would be greate. They want to start offering the service in > > > the > > > beginning of next year. So it is a bit urgend. > > > > > > Best regards, > > > Sander > > > > > > On Mon, 2024-10-28 at 15:38 +0100, Krzysztof Benedyczak wrote: > > > > Hi Sander, > > > > > > > > W dniu 22.10.2024 o 11:27, Sander Apweiler pisze: > > > > > Hello Krzysztof, > > > > > sadly we have another software which requires an optional OAuth > > > > > element. Our storage team wants to use our unity for > > > > > authN&authZ > > > > > against minIO. At the moment it fails because minIO expects the > > > > > kid > > > > > claim in the token, which is optional in standard. Is there a > > > > > possibility to release this in unity as well? > > > > > > > > Yes, absolutely. I even think it is not so much optional... > > > > > > > > Should be easy, we can put it somewhere relatively soon on our > > > > roadmap. > > > > If this is urgent please let us know. > > > > > > > > Best, > > > > Krzysztof > > > > > > > > > > > > > -- > Large-Scale Data Science > Juelich Supercomputing Centre > > phone: +49 2461 61 8847 > fax: +49 2461 61 6656 > email: sa....@fz... > > ----------------------------------------------------------------------- > ----------------------------------------------------------------------- > Forschungszentrum Jülich GmbH > 52425 Jülich > Sitz der Gesellschaft: Jülich > Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 > Vorsitzender des Aufsichtsrats: MinDir Stefan Müller > Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), > Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Ir. Pieter Jansens > ----------------------------------------------------------------------- > ----------------------------------------------------------------------- > > > _______________________________________________ > Unity-idm-discuss mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss > |
|
From: Sander A. <sa....@fz...> - 2024-11-07 09:08:32
|
Dear Roman, do you have an estimation for the release of the patch? Best regards, Sander On Tue, 2024-10-29 at 12:43 +0100, Roman Krysiński wrote: > Good morning Sander, > > OK, we will work on it soon and release it in the 4.0.3 patch. > > Best regards, > Roman > > > wt., 29 paź 2024 o 10:53 Sander Apweiler <sa....@fz...> > napisał(a): > > Good morning Krzysztof, > > this would be greate. They want to start offering the service in > > the > > beginning of next year. So it is a bit urgend. > > > > Best regards, > > Sander > > > > On Mon, 2024-10-28 at 15:38 +0100, Krzysztof Benedyczak wrote: > > > Hi Sander, > > > > > > W dniu 22.10.2024 o 11:27, Sander Apweiler pisze: > > > > Hello Krzysztof, > > > > sadly we have another software which requires an optional OAuth > > > > element. Our storage team wants to use our unity for > > > > authN&authZ > > > > against minIO. At the moment it fails because minIO expects the > > > > kid > > > > claim in the token, which is optional in standard. Is there a > > > > possibility to release this in unity as well? > > > > > > Yes, absolutely. I even think it is not so much optional... > > > > > > Should be easy, we can put it somewhere relatively soon on our > > > roadmap. > > > If this is urgent please let us know. > > > > > > Best, > > > Krzysztof > > > > > > > > -- Large-Scale Data Science Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Ir. Pieter Jansens ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Roman K. <ro...@un...> - 2024-10-29 11:43:33
|
Good morning Sander, OK, we will work on it soon and release it in the 4.0.3 patch. Best regards, Roman wt., 29 paź 2024 o 10:53 Sander Apweiler <sa....@fz...> napisał(a): > Good morning Krzysztof, > this would be greate. They want to start offering the service in the > beginning of next year. So it is a bit urgend. > > Best regards, > Sander > > On Mon, 2024-10-28 at 15:38 +0100, Krzysztof Benedyczak wrote: > > Hi Sander, > > > > W dniu 22.10.2024 o 11:27, Sander Apweiler pisze: > > > Hello Krzysztof, > > > sadly we have another software which requires an optional OAuth > > > element. Our storage team wants to use our unity for authN&authZ > > > against minIO. At the moment it fails because minIO expects the kid > > > claim in the token, which is optional in standard. Is there a > > > possibility to release this in unity as well? > > > > Yes, absolutely. I even think it is not so much optional... > > > > Should be easy, we can put it somewhere relatively soon on our > > roadmap. > > If this is urgent please let us know. > > > > Best, > > Krzysztof > > > > > > -- > Large-Scale Data Science > Juelich Supercomputing Centre > > phone: +49 2461 61 8847 > fax: +49 2461 61 6656 > email: sa....@fz... > > ----------------------------------------------------------------------- > ----------------------------------------------------------------------- > Forschungszentrum Jülich GmbH > 52425 Jülich > Sitz der Gesellschaft: Jülich > Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 > Vorsitzender des Aufsichtsrats: MinDir Stefan Müller > Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), > Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Ir. Pieter Jansens > ----------------------------------------------------------------------- > ----------------------------------------------------------------------- > > > _______________________________________________ > Unity-idm-discuss mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss > |
|
From: Sander A. <sa....@fz...> - 2024-10-29 09:53:04
|
Good morning Krzysztof, this would be greate. They want to start offering the service in the beginning of next year. So it is a bit urgend. Best regards, Sander On Mon, 2024-10-28 at 15:38 +0100, Krzysztof Benedyczak wrote: > Hi Sander, > > W dniu 22.10.2024 o 11:27, Sander Apweiler pisze: > > Hello Krzysztof, > > sadly we have another software which requires an optional OAuth > > element. Our storage team wants to use our unity for authN&authZ > > against minIO. At the moment it fails because minIO expects the kid > > claim in the token, which is optional in standard. Is there a > > possibility to release this in unity as well? > > Yes, absolutely. I even think it is not so much optional... > > Should be easy, we can put it somewhere relatively soon on our > roadmap. > If this is urgent please let us know. > > Best, > Krzysztof > > -- Large-Scale Data Science Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Ir. Pieter Jansens ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Krzysztof B. <kb...@un...> - 2024-10-28 14:39:12
|
Hi Sander, W dniu 22.10.2024 o 11:27, Sander Apweiler pisze: > Hello Krzysztof, > sadly we have another software which requires an optional OAuth > element. Our storage team wants to use our unity for authN&authZ > against minIO. At the moment it fails because minIO expects the kid > claim in the token, which is optional in standard. Is there a > possibility to release this in unity as well? Yes, absolutely. I even think it is not so much optional... Should be easy, we can put it somewhere relatively soon on our roadmap. If this is urgent please let us know. Best, Krzysztof |
|
From: Roman K. <ro...@un...> - 2024-10-28 09:00:22
|
Hello Sander, Thank you for clarifying this, I see your point. I believe that if Unity were more flexible with policy enforcement at the IdP level—such as allowing the configuration of specific policy enforcement for particular groups—the automation you envision might not be necessary. Is this an accurate assessment? This is something we recognize as a potential enhancement, though we currently have no plans for it in our roadmap. Thank you, Roman śr., 25 wrz 2024 o 11:57 Sander Apweiler <sa....@fz...> napisał(a): > Hello Roman, > I'm very sorry for the very long delay. > > If unity does automated management of the policy, I would expect that a > new version, creates an enquiry, which is attached to all users, who > filled up the policy so far, e.g. by adding them to a group. I would > expect this for all versions and not only for the first update. I would > also expect that the "sys:policy-agreement-state" attribute is updated. > > If there is also no automated way for this, which would be also fine, > this needs to be written clearly in the manual and administrators must > create the enquiry after policy updates by themselves. > > Please et me know if something is unclear. > > Best regards, > Sander > > > On Tue, 2024-08-20 at 11:51 +0200, Roman Krysiński wrote: > > Hello Sander, > > > > After discussion w/ the team, we believe there might be still > > misunderstanding of how Policy Documents works. > > Before going into explanations I would like to understand first your > > thinking in this regard. > > > > [Roman] > > As mentioned, if a user had an enquiry already completed, > > revision > > [Roman] > > update will not force the user to re-do the enquiry. > > [Sander] > Ok but the behaviour is not that what I would expect when > > I have policy > > [Sander] > management. Could you please add this to the manual. It > > sounds a bit > > [Sander] > strange to me that you have an automated update rotine for > > the first > > [Sander] > policy revision but not for the later ones. > > > > Can you elaborate on what is the expected behavior? > > And to what automation routine you are referring to? > > > > Thank you, > > Roman > > > > wt., 6 sie 2024 o 11:47 Sander Apweiler <sa....@fz...> > > napisał(a): > > > Good morning Roman, > > > so far we use the policies only in registration forms, not on the > > > IdP > > > level. Since we startet to use groups which have their own policies > > > and > > > updated the top level, we are using them in enquiries too. > > > > > > So far I do not see any reason for not using the IdP level. Are the > > > information (date/time and Policy version) stored in attributes > > > too? > > > And in ehich file I need to configure the policies? > > > > > > Some other comments to your previous mail are inline. > > > > > > > > > On Tue, 2024-08-06 at 11:18 +0200, Roman Krysiński wrote: > > > > Good morning Sander, > > > > > > > > Last but not least for "the third side effect" you've pointed out > > > > - > > > > would it work for you to configure this policy on IdP level? In > > > > such > > > > a case it wouldn't be even needed to create enquiries each time > > > > policy revision changes to force users to accept it. > > > > > > > > Best regards, > > > > Roman > > > > > > > > wt., 6 sie 2024 o 11:09 Roman Krysiński <ro...@un...> > > > > napisał(a): > > > > > Good morning Sander, > > > > > > > > > > Let me summarize features around "Policy documents" and I hope > > > > > that > > > > > will clarify cases you've pointed out in previous email. > > > > > > > > > > Policy documents, that can be defined in "Settings > Policy > > > > > documents" console view, itself do not bring > > > > > enforcement capabilities. > > > > > They can be used in conjunction with registration and enquiry > > > > > forms > > > > > as well as on IdP level. > > > > > * Used on registration form is useful to enforce a specific > > > > > policy > > > > > during user creation, and then record this fact in the system > > > > > (as > > > > > you pointed out in sys:policy-agreement-state attribute) > > > > > * When a policy is used at the IdP level (Vaadin-based IdPs > > > > > contain > > > > > a “Policy Agreements” tab where this can be configured), the > > > > > user > > > > > will be required to see and accept the policy after logging > > > > > into > > > > > such an IdP if the current system policy revision does not > > > > > match > > > > > the one recorded in the user’s sys:policy-agreement-state > > > > > attribute. > > > > > * Policy document can also be used in enquiry, it will be shown > > > > > there only when current system policy revision does not match > > > > > the > > > > > one recorded in the user’s sys:policy-agreement-state > > > > > attribute. In > > > > > other words if the user has already accepted the current > > > > > policy, > > > > > enquiry will not show it. The fact that the user has completed > > > > > specific enquiry is recorded in sys:FilledEnquires attribute. > > > > > > > > > > Note that changing the policy document revision does not > > > > > influence > > > > > on the sys:FilledEnquires, so if e.g. user has completed an > > > > > enquiry > > > > > of "User is requested, mandatory" type, which is configured > > > > > with a > > > > > policy, that revision has changed, then this enquiry will not > > > > > be > > > > > enforced once more. This can be done with new enquiry OR by > > > > > configuring this in IdP level. > > > > > > > > > > > We encountered on Monday the situation where we changed the > > > > > > revision of a policy from > > > > > > version 2 to version 3 (no content changes) and the user did > > > > > > not > > > > > > get > > > > > > the update enquiry because they had it already at the update > > > > > > to > > > > > > version 2. > > > > > As mentioned, if a user had an enquiry already completed, > > > > > revision > > > > > update will not force the user to re-do the enquiry. > > > Ok but the behaviour is not that what I would expect when I have > > > policy > > > management. Could you please add this to the manual. It sounds a > > > bit > > > strange to me that you have an automated update rotine for the > > > first > > > policy revision but not for the later ones. > > > > > > > > > > > We also saw that the update enquiry did not set or update the > > > > > > value > > > > > > of the sys:policy-agreement-state attribute > > > > > Can you confirm that the enquiry request in question was > > > > > accepted? > > > > > If so, could you please provide more details on how to > > > > > reproduce > > > > > the problem? > > > Yes. I added a screen shot. I also have some accounts, which has > > > only > > > the sys:FilledEnquieries attribute from the Update enquire but not > > > the > > > sys:policy-agreeement-state. > > > > > > Best regards, > > > Sander > > > > > > > > > > > > > > (...) a new user account, who agreed the latest version > > > > > > during > > > > > > the > > > > > > registration, got an empty enquiry (no checkbox and policy, > > > > > > but > > > > > > on > > > > > > cancel and submit buttons) at the first login > > > > > As noted, the policy is not shown on enquiry form, when the > > > > > user > > > > > has already accepted it. > > > > > I see your point however that this is not the best user > > > > > experience, > > > > > and there is room for improvement here. > > > > > We will think about this use case and a better handling. > > > > > > > > > > In addition to the problem reported by Piotr with enquiry we've > > > > > found three more items to address and targeted for the 4.0.1 > > > > > patch: > > > > > * Enquiry logout does not work > > > > > * Enquiries are not enforced when logging to hope ui > > > > > * Improve the layout of enquiry buttons > > > > > > > > > > Please let me know in case of any further questions. > > > > > > > > > > Best regards, > > > > > Roman > > > > > > > > > > > > > > > śr., 31 lip 2024 o 07:36 Sander Apweiler > > > > > <sa....@fz...> napisał(a): > > > > > > Good morning, > > > > > > > > > > > > the problems we found were based on unity 3.16.1. We > > > > > > encountered > > > > > > on > > > > > > Monday the situation where we changed the revision of a > > > > > > policy > > > > > > from > > > > > > version 2 to version 3 (no content changes) and the user did > > > > > > not > > > > > > get > > > > > > the update enquiry because they had it already at the update > > > > > > to > > > > > > version > > > > > > 2. We also saw that the update enquiry did not set or update > > > > > > the > > > > > > value > > > > > > of the sys:policy-agreement-state attribute. And the third > > > > > > side > > > > > > effect > > > > > > was that a new user account, who agreed the latest version > > > > > > during > > > > > > the > > > > > > registration, got an empty enquiry (no checkbox and policy, > > > > > > but > > > > > > on > > > > > > cancel and submit buttons) at the first login. Our plan was > > > > > > to > > > > > > verify > > > > > > this on unity 4, before we report those issues. > > > > > > > > > > > > Best regards, > > > > > > Sander > > > > > > > > > > > > > > > > > > On Tue, 2024-07-30 at 15:05 +0200, Piotr Piernik wrote: > > > > > > > Dear Sander > > > > > > > Generally If the policy has changed with the revision > > > > > > > number > > > > > > > increase, > > > > > > > it should appear to users automatically. > > > > > > > Could you please provide more details in which scenario it > > > > > > > won't > > > > > > > work? > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best regards > > > > > > > Piotr > > > > > > > > > > > > > > W dniu 30.07.2024 o 12:36, Sander Apweiler pisze: > > > > > > > > Dear Piotr, > > > > > > > > nice to hear you found the reason. Can you answer my > > > > > > > > second > > > > > > > > question as > > > > > > > > well? We found some issues regarding policies in our > > > > > > > > 3.16.1 > > > > > > > > instances > > > > > > > > and we are not sure if the problems based on our > > > > > > > > misconfiguration > > > > > > > > or > > > > > > > > unity. > > > > > > > > > > > > > > > > Best regards, > > > > > > > > Sander > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 2024-07-30 at 12:20 +0200, Piotr Piernik wrote: > > > > > > > > > > > > > > > > > > Dear Sander > > > > > > > > > We have problem in policy document editor - saves > > > > > > > > > optional > > > > > > > > > policy > > > > > > > > > documents as mandatory and vice versa. > > > > > > > > > We will fix it in 4.0.1 patch. > > > > > > > > > > > > > > > > > > Best regards > > > > > > > > > Piotr > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > W dniu 30.07.2024 o 07:13, Sander Apweiler pisze: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Good morning Krzysztof, > > > > > > > > > > good morning Roman, > > > > > > > > > > > > > > > > > > > > we found another bug in unity 4. We created a > > > > > > > > > > mandatory > > > > > > > > > > policy > > > > > > > > > > (see > > > > > > > > > > 1st > > > > > > > > > > screenshot) and added it to the registration form > > > > > > > > > > (see > > > > > > > > > > 2nd > > > > > > > > > > screenshot). > > > > > > > > > > This policy should be mandatory but I can register > > > > > > > > > > without > > > > > > > > > > confirmation > > > > > > > > > > of the policy. > > > > > > > > > > > > > > > > > > > > Another question regarding policies because I do not > > > > > > > > > > remember > > > > > > > > > > and > > > > > > > > > > the > > > > > > > > > > manual is not that clear in this point. When I create > > > > > > > > > > a > > > > > > > > > > new > > > > > > > > > > version > > > > > > > > > > of > > > > > > > > > > a policy, is the confirmation of the new version > > > > > > > > > > shown to > > > > > > > > > > all > > > > > > > > > > users > > > > > > > > > > or > > > > > > > > > > do I need to create enquieries manually? > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > Sander > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Unity-idm-discuss mailing list > > > > > > > > > > Uni...@li... > > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Large-Scale Data Science > Juelich Supercomputing Centre > > phone: +49 2461 61 8847 > fax: +49 2461 61 6656 > email: sa....@fz... > > ----------------------------------------------------------------------- > ----------------------------------------------------------------------- > Forschungszentrum Jülich GmbH > 52425 Jülich > Sitz der Gesellschaft: Jülich > Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 > Vorsitzender des Aufsichtsrats: MinDir Stefan Müller > Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), > Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Ir. Pieter Jansens > ----------------------------------------------------------------------- > ----------------------------------------------------------------------- > > > |
|
From: Sander A. <sa....@fz...> - 2024-10-22 09:27:32
|
Hello Krzysztof, sadly we have another software which requires an optional OAuth element. Our storage team wants to use our unity for authN&authZ against minIO. At the moment it fails because minIO expects the kid claim in the token, which is optional in standard. Is there a possibility to release this in unity as well? Best regards, Sander -- Large-Scale Data Science Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Ir. Pieter Jansens ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Krzysztof B. <kb...@un...> - 2024-10-20 12:05:13
|
Dear Subscribers,
I'm happy to share that a new patch release 4.0.2 is available.
In this patch we were focused on improving the following problems:
* *Mail subsystem*: several problems were reported, which were
resulting from updates of external dependencies.
* *Performance* in case of big user directories, related to
invitations and registration handling.
* Editing of *image* type *attributes.*
All relevant links are available here:
https://unity-idm.eu/releases/release-4-0-2/
Best regards,
Krzysztof
|
|
From: Sander A. <sa....@fz...> - 2024-09-25 10:16:08
|
Hello Roman, I'm very sorry for the very long delay. If unity does automated management of the policy, I would expect that a new version, creates an enquiry, which is attached to all users, who filled up the policy so far, e.g. by adding them to a group. I would expect this for all versions and not only for the first update. I would also expect that the "sys:policy-agreement-state" attribute is updated. If there is also no automated way for this, which would be also fine, this needs to be written clearly in the manual and administrators must create the enquiry after policy updates by themselves. Please et me know if something is unclear. Best regards, Sander On Tue, 2024-08-20 at 11:51 +0200, Roman Krysiński wrote: > Hello Sander, > > After discussion w/ the team, we believe there might be still > misunderstanding of how Policy Documents works. > Before going into explanations I would like to understand first your > thinking in this regard. > > [Roman] > > As mentioned, if a user had an enquiry already completed, > revision > [Roman] > > update will not force the user to re-do the enquiry. > [Sander] > Ok but the behaviour is not that what I would expect when > I have policy > [Sander] > management. Could you please add this to the manual. It > sounds a bit > [Sander] > strange to me that you have an automated update rotine for > the first > [Sander] > policy revision but not for the later ones. > > Can you elaborate on what is the expected behavior? > And to what automation routine you are referring to? > > Thank you, > Roman > > wt., 6 sie 2024 o 11:47 Sander Apweiler <sa....@fz...> > napisał(a): > > Good morning Roman, > > so far we use the policies only in registration forms, not on the > > IdP > > level. Since we startet to use groups which have their own policies > > and > > updated the top level, we are using them in enquiries too. > > > > So far I do not see any reason for not using the IdP level. Are the > > information (date/time and Policy version) stored in attributes > > too? > > And in ehich file I need to configure the policies? > > > > Some other comments to your previous mail are inline. > > > > > > On Tue, 2024-08-06 at 11:18 +0200, Roman Krysiński wrote: > > > Good morning Sander, > > > > > > Last but not least for "the third side effect" you've pointed out > > > - > > > would it work for you to configure this policy on IdP level? In > > > such > > > a case it wouldn't be even needed to create enquiries each time > > > policy revision changes to force users to accept it. > > > > > > Best regards, > > > Roman > > > > > > wt., 6 sie 2024 o 11:09 Roman Krysiński <ro...@un...> > > > napisał(a): > > > > Good morning Sander, > > > > > > > > Let me summarize features around "Policy documents" and I hope > > > > that > > > > will clarify cases you've pointed out in previous email. > > > > > > > > Policy documents, that can be defined in "Settings > Policy > > > > documents" console view, itself do not bring > > > > enforcement capabilities. > > > > They can be used in conjunction with registration and enquiry > > > > forms > > > > as well as on IdP level. > > > > * Used on registration form is useful to enforce a specific > > > > policy > > > > during user creation, and then record this fact in the system > > > > (as > > > > you pointed out in sys:policy-agreement-state attribute) > > > > * When a policy is used at the IdP level (Vaadin-based IdPs > > > > contain > > > > a “Policy Agreements” tab where this can be configured), the > > > > user > > > > will be required to see and accept the policy after logging > > > > into > > > > such an IdP if the current system policy revision does not > > > > match > > > > the one recorded in the user’s sys:policy-agreement-state > > > > attribute. > > > > * Policy document can also be used in enquiry, it will be shown > > > > there only when current system policy revision does not match > > > > the > > > > one recorded in the user’s sys:policy-agreement-state > > > > attribute. In > > > > other words if the user has already accepted the current > > > > policy, > > > > enquiry will not show it. The fact that the user has completed > > > > specific enquiry is recorded in sys:FilledEnquires attribute. > > > > > > > > Note that changing the policy document revision does not > > > > influence > > > > on the sys:FilledEnquires, so if e.g. user has completed an > > > > enquiry > > > > of "User is requested, mandatory" type, which is configured > > > > with a > > > > policy, that revision has changed, then this enquiry will not > > > > be > > > > enforced once more. This can be done with new enquiry OR by > > > > configuring this in IdP level. > > > > > > > > > We encountered on Monday the situation where we changed the > > > > > revision of a policy from > > > > > version 2 to version 3 (no content changes) and the user did > > > > > not > > > > > get > > > > > the update enquiry because they had it already at the update > > > > > to > > > > > version 2. > > > > As mentioned, if a user had an enquiry already completed, > > > > revision > > > > update will not force the user to re-do the enquiry. > > Ok but the behaviour is not that what I would expect when I have > > policy > > management. Could you please add this to the manual. It sounds a > > bit > > strange to me that you have an automated update rotine for the > > first > > policy revision but not for the later ones. > > > > > > > > > We also saw that the update enquiry did not set or update the > > > > > value > > > > > of the sys:policy-agreement-state attribute > > > > Can you confirm that the enquiry request in question was > > > > accepted? > > > > If so, could you please provide more details on how to > > > > reproduce > > > > the problem? > > Yes. I added a screen shot. I also have some accounts, which has > > only > > the sys:FilledEnquieries attribute from the Update enquire but not > > the > > sys:policy-agreeement-state. > > > > Best regards, > > Sander > > > > > > > > > > > (...) a new user account, who agreed the latest version > > > > > during > > > > > the > > > > > registration, got an empty enquiry (no checkbox and policy, > > > > > but > > > > > on > > > > > cancel and submit buttons) at the first login > > > > As noted, the policy is not shown on enquiry form, when the > > > > user > > > > has already accepted it. > > > > I see your point however that this is not the best user > > > > experience, > > > > and there is room for improvement here. > > > > We will think about this use case and a better handling. > > > > > > > > In addition to the problem reported by Piotr with enquiry we've > > > > found three more items to address and targeted for the 4.0.1 > > > > patch: > > > > * Enquiry logout does not work > > > > * Enquiries are not enforced when logging to hope ui > > > > * Improve the layout of enquiry buttons > > > > > > > > Please let me know in case of any further questions. > > > > > > > > Best regards, > > > > Roman > > > > > > > > > > > > śr., 31 lip 2024 o 07:36 Sander Apweiler > > > > <sa....@fz...> napisał(a): > > > > > Good morning, > > > > > > > > > > the problems we found were based on unity 3.16.1. We > > > > > encountered > > > > > on > > > > > Monday the situation where we changed the revision of a > > > > > policy > > > > > from > > > > > version 2 to version 3 (no content changes) and the user did > > > > > not > > > > > get > > > > > the update enquiry because they had it already at the update > > > > > to > > > > > version > > > > > 2. We also saw that the update enquiry did not set or update > > > > > the > > > > > value > > > > > of the sys:policy-agreement-state attribute. And the third > > > > > side > > > > > effect > > > > > was that a new user account, who agreed the latest version > > > > > during > > > > > the > > > > > registration, got an empty enquiry (no checkbox and policy, > > > > > but > > > > > on > > > > > cancel and submit buttons) at the first login. Our plan was > > > > > to > > > > > verify > > > > > this on unity 4, before we report those issues. > > > > > > > > > > Best regards, > > > > > Sander > > > > > > > > > > > > > > > On Tue, 2024-07-30 at 15:05 +0200, Piotr Piernik wrote: > > > > > > Dear Sander > > > > > > Generally If the policy has changed with the revision > > > > > > number > > > > > > increase, > > > > > > it should appear to users automatically. > > > > > > Could you please provide more details in which scenario it > > > > > > won't > > > > > > work? > > > > > > > > > > > > > > > > > > > > > > > > Best regards > > > > > > Piotr > > > > > > > > > > > > W dniu 30.07.2024 o 12:36, Sander Apweiler pisze: > > > > > > > Dear Piotr, > > > > > > > nice to hear you found the reason. Can you answer my > > > > > > > second > > > > > > > question as > > > > > > > well? We found some issues regarding policies in our > > > > > > > 3.16.1 > > > > > > > instances > > > > > > > and we are not sure if the problems based on our > > > > > > > misconfiguration > > > > > > > or > > > > > > > unity. > > > > > > > > > > > > > > Best regards, > > > > > > > Sander > > > > > > > > > > > > > > > > > > > > > On Tue, 2024-07-30 at 12:20 +0200, Piotr Piernik wrote: > > > > > > > > > > > > > > > > Dear Sander > > > > > > > > We have problem in policy document editor - saves > > > > > > > > optional > > > > > > > > policy > > > > > > > > documents as mandatory and vice versa. > > > > > > > > We will fix it in 4.0.1 patch. > > > > > > > > > > > > > > > > Best regards > > > > > > > > Piotr > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > W dniu 30.07.2024 o 07:13, Sander Apweiler pisze: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Good morning Krzysztof, > > > > > > > > > good morning Roman, > > > > > > > > > > > > > > > > > > we found another bug in unity 4. We created a > > > > > > > > > mandatory > > > > > > > > > policy > > > > > > > > > (see > > > > > > > > > 1st > > > > > > > > > screenshot) and added it to the registration form > > > > > > > > > (see > > > > > > > > > 2nd > > > > > > > > > screenshot). > > > > > > > > > This policy should be mandatory but I can register > > > > > > > > > without > > > > > > > > > confirmation > > > > > > > > > of the policy. > > > > > > > > > > > > > > > > > > Another question regarding policies because I do not > > > > > > > > > remember > > > > > > > > > and > > > > > > > > > the > > > > > > > > > manual is not that clear in this point. When I create > > > > > > > > > a > > > > > > > > > new > > > > > > > > > version > > > > > > > > > of > > > > > > > > > a policy, is the confirmation of the new version > > > > > > > > > shown to > > > > > > > > > all > > > > > > > > > users > > > > > > > > > or > > > > > > > > > do I need to create enquieries manually? > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > Sander > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Unity-idm-discuss mailing list > > > > > > > > > Uni...@li... > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss > > > > > > > > > > > > > > > > > > > > > > > > -- Large-Scale Data Science Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Ir. Pieter Jansens ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Krzysztof B. <kb...@un...> - 2024-08-21 12:01:21
|
Dear Subscribers, Unity 4.0.1 patch was released. In this patch release we were focused on improving various problems found in major 4.0.0 release. It contains over a dozen of fixes improving the overall stability. For more details and download links see https://unity-idm.eu/releases/release-4-0-1/ Best regards, Krzysztof |
|
From: Krzysztof B. <kb...@un...> - 2024-08-21 09:27:27
|
Hi Sander, W dniu 19.08.2024 o 10:22, Sander Apweiler pisze: > Good morning Krzystof, > good morning Roman, > > > We are setting up a new unity instance as proxy for services offered by > our institute. This should give users always the same look and feel in > the login. The main account source is a local OP, but it is also > connected to a few selected external OPs. > > Another condition is that users shall have only one account. For this > reason we are using the email address as a second identifier, beside > the sub of OIDC. As far as I understood we must use the "REQUIRE_MATCH" > policy if both identifiers must match. Can you confirm this? When we > are using the "REQUIRE_MATCH" user must create an account, e.g. via No > account? Sign up! link in the UI before they login to unity in the > normal login flow. Can you confirm this, too? When we use the > "CREATE_OR_MATCH" policy unity recognises that users are not registered > in the system, if the users login for the first time, but unity would > start merging users only by the email from different OPs. Since email > addresses are reused in time, we do not want to have a implicit merge > by email address only. I'm not 100% sure if I understood all the details here, but roughly all of the above sounds correct to me. > In 9 years of operating those kind of proxies, we made the experience, > the users do not follow the No Account? Sign Up link, if they see the > big WAYF and can select their home organisation. Also service providers > do not want to have this additional step of clicking on the > registration button before users can start using the service. > Do you see any possibilities to have the identity mapping like > REQUIRE_MATCH but display the registration/associate buttons, if the > user is not known in the system? Yes, use the MATCH policy. If there will be no match, Unity can show an option to register after failed login (you have to setup a registration form for unknown users: you may also enable an option to associate remotely authenticated user with an existing account (there is a checkbox on authenticator). The registration form that you will link can be prefilled with data coming from remote IdP, as well as you have access to it in form's automation rules. HTH, Krzysztof |
|
From: Roman K. <ro...@un...> - 2024-08-20 09:52:00
|
Hello Sander, After discussion w/ the team, we believe there might be still misunderstanding of how Policy Documents works. Before going into explanations I would like to understand first your thinking in this regard. [Roman] > > As mentioned, if a user had an enquiry already completed, revision [Roman] > > update will not force the user to re-do the enquiry. [Sander] > Ok but the behaviour is not that what I would expect when I have policy [Sander] > management. Could you please add this to the manual. It sounds a bit [Sander] > strange to me that you have an automated update rotine for the first [Sander] > policy revision but not for the later ones. Can you elaborate on what is the expected behavior? And to what automation routine you are referring to? Thank you, Roman wt., 6 sie 2024 o 11:47 Sander Apweiler <sa....@fz...> napisał(a): > Good morning Roman, > so far we use the policies only in registration forms, not on the IdP > level. Since we startet to use groups which have their own policies and > updated the top level, we are using them in enquiries too. > > So far I do not see any reason for not using the IdP level. Are the > information (date/time and Policy version) stored in attributes too? > And in ehich file I need to configure the policies? > > Some other comments to your previous mail are inline. > > > On Tue, 2024-08-06 at 11:18 +0200, Roman Krysiński wrote: > > Good morning Sander, > > > > Last but not least for "the third side effect" you've pointed out - > > would it work for you to configure this policy on IdP level? In such > > a case it wouldn't be even needed to create enquiries each time > > policy revision changes to force users to accept it. > > > > Best regards, > > Roman > > > > wt., 6 sie 2024 o 11:09 Roman Krysiński <ro...@un...> > > napisał(a): > > > Good morning Sander, > > > > > > Let me summarize features around "Policy documents" and I hope that > > > will clarify cases you've pointed out in previous email. > > > > > > Policy documents, that can be defined in "Settings > Policy > > > documents" console view, itself do not bring > > > enforcement capabilities. > > > They can be used in conjunction with registration and enquiry forms > > > as well as on IdP level. > > > * Used on registration form is useful to enforce a specific policy > > > during user creation, and then record this fact in the system (as > > > you pointed out in sys:policy-agreement-state attribute) > > > * When a policy is used at the IdP level (Vaadin-based IdPs contain > > > a “Policy Agreements” tab where this can be configured), the user > > > will be required to see and accept the policy after logging into > > > such an IdP if the current system policy revision does not match > > > the one recorded in the user’s sys:policy-agreement-state > > > attribute. > > > * Policy document can also be used in enquiry, it will be shown > > > there only when current system policy revision does not match the > > > one recorded in the user’s sys:policy-agreement-state attribute. In > > > other words if the user has already accepted the current policy, > > > enquiry will not show it. The fact that the user has completed > > > specific enquiry is recorded in sys:FilledEnquires attribute. > > > > > > Note that changing the policy document revision does not influence > > > on the sys:FilledEnquires, so if e.g. user has completed an enquiry > > > of "User is requested, mandatory" type, which is configured with a > > > policy, that revision has changed, then this enquiry will not be > > > enforced once more. This can be done with new enquiry OR by > > > configuring this in IdP level. > > > > > > > We encountered on Monday the situation where we changed the > > > > revision of a policy from > > > > version 2 to version 3 (no content changes) and the user did not > > > > get > > > > the update enquiry because they had it already at the update to > > > > version 2. > > > As mentioned, if a user had an enquiry already completed, revision > > > update will not force the user to re-do the enquiry. > Ok but the behaviour is not that what I would expect when I have policy > management. Could you please add this to the manual. It sounds a bit > strange to me that you have an automated update rotine for the first > policy revision but not for the later ones. > > > > > > > We also saw that the update enquiry did not set or update the > > > > value > > > > of the sys:policy-agreement-state attribute > > > Can you confirm that the enquiry request in question was accepted? > > > If so, could you please provide more details on how to reproduce > > > the problem? > Yes. I added a screen shot. I also have some accounts, which has only > the sys:FilledEnquieries attribute from the Update enquire but not the > sys:policy-agreeement-state. > > Best regards, > Sander > > > > > > > > (...) a new user account, who agreed the latest version during > > > > the > > > > registration, got an empty enquiry (no checkbox and policy, but > > > > on > > > > cancel and submit buttons) at the first login > > > As noted, the policy is not shown on enquiry form, when the user > > > has already accepted it. > > > I see your point however that this is not the best user experience, > > > and there is room for improvement here. > > > We will think about this use case and a better handling. > > > > > > In addition to the problem reported by Piotr with enquiry we've > > > found three more items to address and targeted for the 4.0.1 patch: > > > * Enquiry logout does not work > > > * Enquiries are not enforced when logging to hope ui > > > * Improve the layout of enquiry buttons > > > > > > Please let me know in case of any further questions. > > > > > > Best regards, > > > Roman > > > > > > > > > śr., 31 lip 2024 o 07:36 Sander Apweiler > > > <sa....@fz...> napisał(a): > > > > Good morning, > > > > > > > > the problems we found were based on unity 3.16.1. We encountered > > > > on > > > > Monday the situation where we changed the revision of a policy > > > > from > > > > version 2 to version 3 (no content changes) and the user did not > > > > get > > > > the update enquiry because they had it already at the update to > > > > version > > > > 2. We also saw that the update enquiry did not set or update the > > > > value > > > > of the sys:policy-agreement-state attribute. And the third side > > > > effect > > > > was that a new user account, who agreed the latest version during > > > > the > > > > registration, got an empty enquiry (no checkbox and policy, but > > > > on > > > > cancel and submit buttons) at the first login. Our plan was to > > > > verify > > > > this on unity 4, before we report those issues. > > > > > > > > Best regards, > > > > Sander > > > > > > > > > > > > On Tue, 2024-07-30 at 15:05 +0200, Piotr Piernik wrote: > > > > > Dear Sander > > > > > Generally If the policy has changed with the revision number > > > > > increase, > > > > > it should appear to users automatically. > > > > > Could you please provide more details in which scenario it > > > > > won't > > > > > work? > > > > > > > > > > > > > > > > > > > > Best regards > > > > > Piotr > > > > > > > > > > W dniu 30.07.2024 o 12:36, Sander Apweiler pisze: > > > > > > Dear Piotr, > > > > > > nice to hear you found the reason. Can you answer my second > > > > > > question as > > > > > > well? We found some issues regarding policies in our 3.16.1 > > > > > > instances > > > > > > and we are not sure if the problems based on our > > > > > > misconfiguration > > > > > > or > > > > > > unity. > > > > > > > > > > > > Best regards, > > > > > > Sander > > > > > > > > > > > > > > > > > > On Tue, 2024-07-30 at 12:20 +0200, Piotr Piernik wrote: > > > > > > > > > > > > > > Dear Sander > > > > > > > We have problem in policy document editor - saves > > > > > > > optional > > > > > > > policy > > > > > > > documents as mandatory and vice versa. > > > > > > > We will fix it in 4.0.1 patch. > > > > > > > > > > > > > > Best regards > > > > > > > Piotr > > > > > > > > > > > > > > > > > > > > > > > > > > > > W dniu 30.07.2024 o 07:13, Sander Apweiler pisze: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Good morning Krzysztof, > > > > > > > > good morning Roman, > > > > > > > > > > > > > > > > we found another bug in unity 4. We created a mandatory > > > > > > > > policy > > > > > > > > (see > > > > > > > > 1st > > > > > > > > screenshot) and added it to the registration form (see > > > > > > > > 2nd > > > > > > > > screenshot). > > > > > > > > This policy should be mandatory but I can register > > > > > > > > without > > > > > > > > confirmation > > > > > > > > of the policy. > > > > > > > > > > > > > > > > Another question regarding policies because I do not > > > > > > > > remember > > > > > > > > and > > > > > > > > the > > > > > > > > manual is not that clear in this point. When I create a > > > > > > > > new > > > > > > > > version > > > > > > > > of > > > > > > > > a policy, is the confirmation of the new version shown to > > > > > > > > all > > > > > > > > users > > > > > > > > or > > > > > > > > do I need to create enquieries manually? > > > > > > > > > > > > > > > > Best regards, > > > > > > > > Sander > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Unity-idm-discuss mailing list > > > > > > > > Uni...@li... > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss > > > > > > > > > > > > > > > > > > > > > -- > Large-Scale Data Science > Juelich Supercomputing Centre > > phone: +49 2461 61 8847 > fax: +49 2461 61 6656 > email: sa....@fz... > > ----------------------------------------------------------------------- > ----------------------------------------------------------------------- > Forschungszentrum Jülich GmbH > 52425 Jülich > Sitz der Gesellschaft: Jülich > Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 > Vorsitzender des Aufsichtsrats: MinDir Stefan Müller > Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), > Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Ir. Pieter Jansens > ----------------------------------------------------------------------- > ----------------------------------------------------------------------- > > > _______________________________________________ > Unity-idm-discuss mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss > |
|
From: Sander A. <sa....@fz...> - 2024-08-19 08:22:18
|
Good morning Krzystof, good morning Roman, We are setting up a new unity instance as proxy for services offered by our institute. This should give users always the same look and feel in the login. The main account source is a local OP, but it is also connected to a few selected external OPs. Another condition is that users shall have only one account. For this reason we are using the email address as a second identifier, beside the sub of OIDC. As far as I understood we must use the "REQUIRE_MATCH" policy if both identifiers must match. Can you confirm this? When we are using the "REQUIRE_MATCH" user must create an account, e.g. via No account? Sign up! link in the UI before they login to unity in the normal login flow. Can you confirm this, too? When we use the "CREATE_OR_MATCH" policy unity recognises that users are not registered in the system, if the users login for the first time, but unity would start merging users only by the email from different OPs. Since email addresses are reused in time, we do not want to have a implicit merge by email address only. In 9 years of operating those kind of proxies, we made the experience, the users do not follow the No Account? Sign Up link, if they see the big WAYF and can select their home organisation. Also service providers do not want to have this additional step of clicking on the registration button before users can start using the service. Do you see any possibilities to have the identity mapping like REQUIRE_MATCH but display the registration/associate buttons, if the user is not known in the system? Best regards, Sander -- Large-Scale Data Science Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Ir. Pieter Jansens ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Krzysztof B. <kb...@un...> - 2024-08-16 08:39:20
|
Hi Sander, W dniu 15.08.2024 o 08:11, Sander Apweiler pisze: > Good morning Krzysztof, > good morning Roman, > > We were ask by our users/providers of services if unity can support > back-channel logout [1]. As far as we can see this is not the case. Do > you have any plans about this? > Unfortunately not. It is on the radar, but currently quite far in the backlog (after general performance and MFA improvements). Best, Krzysztof |
|
From: Sander A. <sa....@fz...> - 2024-08-15 06:11:25
|
Good morning Krzysztof, good morning Roman, We were ask by our users/providers of services if unity can support back-channel logout [1]. As far as we can see this is not the case. Do you have any plans about this? Best regards, Sander [1]: https://openid.net/specs/openid-connect-backchannel-1_0.html -- Large-Scale Data Science Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Ir. Pieter Jansens ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Roman K. <ro...@un...> - 2024-08-14 06:09:21
|
Good morning Sander, > Are the information (date/time and Policy version) stored in attributes too? Yes > And in ehich file I need to configure the policies? On the IdP level, in case of OAuth IdP take a look at OAuth 2 Authorization Server and OpenId Connect endpoints <https://www.unity-idm.eu/documentation/unity-4.0.0/manual.html> section of manual and properties w/ policyAgreements in name e.g. unity.oauth2.as.policyAgreements, unity.oauth2.as .policyAgreementsInfo etc. We are processing the rest of your input from this email thread, stay tuned. Thank you for your patience, Roman wt., 6 sie 2024 o 11:47 Sander Apweiler <sa....@fz...> napisał(a): > Good morning Roman, > so far we use the policies only in registration forms, not on the IdP > level. Since we startet to use groups which have their own policies and > updated the top level, we are using them in enquiries too. > > So far I do not see any reason for not using the IdP level. Are the > information (date/time and Policy version) stored in attributes too? > And in ehich file I need to configure the policies? > > Some other comments to your previous mail are inline. > > > On Tue, 2024-08-06 at 11:18 +0200, Roman Krysiński wrote: > > Good morning Sander, > > > > Last but not least for "the third side effect" you've pointed out - > > would it work for you to configure this policy on IdP level? In such > > a case it wouldn't be even needed to create enquiries each time > > policy revision changes to force users to accept it. > > > > Best regards, > > Roman > > > > wt., 6 sie 2024 o 11:09 Roman Krysiński <ro...@un...> > > napisał(a): > > > Good morning Sander, > > > > > > Let me summarize features around "Policy documents" and I hope that > > > will clarify cases you've pointed out in previous email. > > > > > > Policy documents, that can be defined in "Settings > Policy > > > documents" console view, itself do not bring > > > enforcement capabilities. > > > They can be used in conjunction with registration and enquiry forms > > > as well as on IdP level. > > > * Used on registration form is useful to enforce a specific policy > > > during user creation, and then record this fact in the system (as > > > you pointed out in sys:policy-agreement-state attribute) > > > * When a policy is used at the IdP level (Vaadin-based IdPs contain > > > a “Policy Agreements” tab where this can be configured), the user > > > will be required to see and accept the policy after logging into > > > such an IdP if the current system policy revision does not match > > > the one recorded in the user’s sys:policy-agreement-state > > > attribute. > > > * Policy document can also be used in enquiry, it will be shown > > > there only when current system policy revision does not match the > > > one recorded in the user’s sys:policy-agreement-state attribute. In > > > other words if the user has already accepted the current policy, > > > enquiry will not show it. The fact that the user has completed > > > specific enquiry is recorded in sys:FilledEnquires attribute. > > > > > > Note that changing the policy document revision does not influence > > > on the sys:FilledEnquires, so if e.g. user has completed an enquiry > > > of "User is requested, mandatory" type, which is configured with a > > > policy, that revision has changed, then this enquiry will not be > > > enforced once more. This can be done with new enquiry OR by > > > configuring this in IdP level. > > > > > > > We encountered on Monday the situation where we changed the > > > > revision of a policy from > > > > version 2 to version 3 (no content changes) and the user did not > > > > get > > > > the update enquiry because they had it already at the update to > > > > version 2. > > > As mentioned, if a user had an enquiry already completed, revision > > > update will not force the user to re-do the enquiry. > Ok but the behaviour is not that what I would expect when I have policy > management. Could you please add this to the manual. It sounds a bit > strange to me that you have an automated update rotine for the first > policy revision but not for the later ones. > > > > > > > We also saw that the update enquiry did not set or update the > > > > value > > > > of the sys:policy-agreement-state attribute > > > Can you confirm that the enquiry request in question was accepted? > > > If so, could you please provide more details on how to reproduce > > > the problem? > Yes. I added a screen shot. I also have some accounts, which has only > the sys:FilledEnquieries attribute from the Update enquire but not the > sys:policy-agreeement-state. > > Best regards, > Sander > > > > > > > > (...) a new user account, who agreed the latest version during > > > > the > > > > registration, got an empty enquiry (no checkbox and policy, but > > > > on > > > > cancel and submit buttons) at the first login > > > As noted, the policy is not shown on enquiry form, when the user > > > has already accepted it. > > > I see your point however that this is not the best user experience, > > > and there is room for improvement here. > > > We will think about this use case and a better handling. > > > > > > In addition to the problem reported by Piotr with enquiry we've > > > found three more items to address and targeted for the 4.0.1 patch: > > > * Enquiry logout does not work > > > * Enquiries are not enforced when logging to hope ui > > > * Improve the layout of enquiry buttons > > > > > > Please let me know in case of any further questions. > > > > > > Best regards, > > > Roman > > > > > > > > > śr., 31 lip 2024 o 07:36 Sander Apweiler > > > <sa....@fz...> napisał(a): > > > > Good morning, > > > > > > > > the problems we found were based on unity 3.16.1. We encountered > > > > on > > > > Monday the situation where we changed the revision of a policy > > > > from > > > > version 2 to version 3 (no content changes) and the user did not > > > > get > > > > the update enquiry because they had it already at the update to > > > > version > > > > 2. We also saw that the update enquiry did not set or update the > > > > value > > > > of the sys:policy-agreement-state attribute. And the third side > > > > effect > > > > was that a new user account, who agreed the latest version during > > > > the > > > > registration, got an empty enquiry (no checkbox and policy, but > > > > on > > > > cancel and submit buttons) at the first login. Our plan was to > > > > verify > > > > this on unity 4, before we report those issues. > > > > > > > > Best regards, > > > > Sander > > > > > > > > > > > > On Tue, 2024-07-30 at 15:05 +0200, Piotr Piernik wrote: > > > > > Dear Sander > > > > > Generally If the policy has changed with the revision number > > > > > increase, > > > > > it should appear to users automatically. > > > > > Could you please provide more details in which scenario it > > > > > won't > > > > > work? > > > > > > > > > > > > > > > > > > > > Best regards > > > > > Piotr > > > > > > > > > > W dniu 30.07.2024 o 12:36, Sander Apweiler pisze: > > > > > > Dear Piotr, > > > > > > nice to hear you found the reason. Can you answer my second > > > > > > question as > > > > > > well? We found some issues regarding policies in our 3.16.1 > > > > > > instances > > > > > > and we are not sure if the problems based on our > > > > > > misconfiguration > > > > > > or > > > > > > unity. > > > > > > > > > > > > Best regards, > > > > > > Sander > > > > > > > > > > > > > > > > > > On Tue, 2024-07-30 at 12:20 +0200, Piotr Piernik wrote: > > > > > > > > > > > > > > Dear Sander > > > > > > > We have problem in policy document editor - saves > > > > > > > optional > > > > > > > policy > > > > > > > documents as mandatory and vice versa. > > > > > > > We will fix it in 4.0.1 patch. > > > > > > > > > > > > > > Best regards > > > > > > > Piotr > > > > > > > > > > > > > > > > > > > > > > > > > > > > W dniu 30.07.2024 o 07:13, Sander Apweiler pisze: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Good morning Krzysztof, > > > > > > > > good morning Roman, > > > > > > > > > > > > > > > > we found another bug in unity 4. We created a mandatory > > > > > > > > policy > > > > > > > > (see > > > > > > > > 1st > > > > > > > > screenshot) and added it to the registration form (see > > > > > > > > 2nd > > > > > > > > screenshot). > > > > > > > > This policy should be mandatory but I can register > > > > > > > > without > > > > > > > > confirmation > > > > > > > > of the policy. > > > > > > > > > > > > > > > > Another question regarding policies because I do not > > > > > > > > remember > > > > > > > > and > > > > > > > > the > > > > > > > > manual is not that clear in this point. When I create a > > > > > > > > new > > > > > > > > version > > > > > > > > of > > > > > > > > a policy, is the confirmation of the new version shown to > > > > > > > > all > > > > > > > > users > > > > > > > > or > > > > > > > > do I need to create enquieries manually? > > > > > > > > > > > > > > > > Best regards, > > > > > > > > Sander > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Unity-idm-discuss mailing list > > > > > > > > Uni...@li... > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss > > > > > > > > > > > > > > > > > > > > > -- > Large-Scale Data Science > Juelich Supercomputing Centre > > phone: +49 2461 61 8847 > fax: +49 2461 61 6656 > email: sa....@fz... > > ----------------------------------------------------------------------- > ----------------------------------------------------------------------- > Forschungszentrum Jülich GmbH > 52425 Jülich > Sitz der Gesellschaft: Jülich > Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 > Vorsitzender des Aufsichtsrats: MinDir Stefan Müller > Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), > Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Ir. Pieter Jansens > ----------------------------------------------------------------------- > ----------------------------------------------------------------------- > > > _______________________________________________ > Unity-idm-discuss mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss > |
|
From: Krzysztof B. <kb...@un...> - 2024-08-13 09:42:53
|
Hi Sander, W dniu 12.08.2024 o 12:06, Sander Apweiler pisze: > Hi Krzysztof, > > most IdPs are only releasing the information about usage of the second > factor via authnContextClassRef if the service (in this case unity), > requested the usage. So the question is, does unity request the usage > of a second factor to the IdP if it is configured? No, however my main point is that I believe there is no option to configure that. Unity recently received dynamic activation of its 2nd factor, it can be triggered taking into account the information on mfa use by upstream IdP, but I believe there is no option to request specific auth context class ref. Best, Krzysztof |
|
From: Sander A. <sa....@fz...> - 2024-08-12 10:06:38
|
Hi Krzysztof, most IdPs are only releasing the information about usage of the second factor via authnContextClassRef if the service (in this case unity), requested the usage. So the question is, does unity request the usage of a second factor to the IdP if it is configured? Best regards, Sander On Mon, 2024-08-12 at 11:35 +0200, Krzysztof Benedyczak wrote: > Hi Sander, > > W dniu 8.08.2024 o 08:11, Sander Apweiler pisze: > > Good morning Krzysztof, > > good morning Roman, > > > > we start testing the dynamic second factor, where unity performs it > > only if it was not performed at the upstream IdP. The IdPs send > > this > > information only if it was requested by the SP. Does unity send > > this > > request, if the dynamic2f flow was performed? > > Can you please specify what request you are wondering about? Meaning > how > SP shall request this information? > > > Best, > Krzysztof > -- Large-Scale Data Science Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Ir. Pieter Jansens ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Krzysztof B. <kb...@un...> - 2024-08-12 09:35:55
|
Hi Sander, W dniu 8.08.2024 o 08:11, Sander Apweiler pisze: > Good morning Krzysztof, > good morning Roman, > > we start testing the dynamic second factor, where unity performs it > only if it was not performed at the upstream IdP. The IdPs send this > information only if it was requested by the SP. Does unity send this > request, if the dynamic2f flow was performed? Can you please specify what request you are wondering about? Meaning how SP shall request this information? Best, Krzysztof |
