You can subscribe to this list here.
2014 |
Jan
(3) |
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(2) |
Aug
(2) |
Sep
|
Oct
(3) |
Nov
|
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2015 |
Jan
(20) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
(15) |
Jul
(1) |
Aug
(7) |
Sep
(13) |
Oct
(2) |
Nov
(10) |
Dec
(1) |
2016 |
Jan
|
Feb
(2) |
Mar
|
Apr
(2) |
May
(1) |
Jun
|
Jul
(1) |
Aug
(2) |
Sep
(11) |
Oct
(7) |
Nov
(6) |
Dec
(11) |
2017 |
Jan
(10) |
Feb
(5) |
Mar
(27) |
Apr
(34) |
May
(25) |
Jun
(14) |
Jul
(7) |
Aug
(17) |
Sep
(11) |
Oct
(6) |
Nov
(14) |
Dec
(10) |
2018 |
Jan
(8) |
Feb
(19) |
Mar
(40) |
Apr
(9) |
May
(16) |
Jun
(23) |
Jul
(31) |
Aug
(7) |
Sep
(9) |
Oct
(6) |
Nov
(14) |
Dec
(19) |
2019 |
Jan
(4) |
Feb
(6) |
Mar
(1) |
Apr
(2) |
May
(6) |
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(19) |
Dec
(14) |
2020 |
Jan
(10) |
Feb
(24) |
Mar
(49) |
Apr
(26) |
May
(12) |
Jun
(4) |
Jul
(13) |
Aug
(32) |
Sep
(13) |
Oct
(10) |
Nov
(4) |
Dec
(16) |
2021 |
Jan
(2) |
Feb
(8) |
Mar
(15) |
Apr
(19) |
May
(5) |
Jun
(13) |
Jul
(6) |
Aug
(38) |
Sep
(11) |
Oct
(18) |
Nov
(11) |
Dec
(13) |
2022 |
Jan
(10) |
Feb
(21) |
Mar
(28) |
Apr
(3) |
May
(7) |
Jun
(9) |
Jul
(14) |
Aug
(13) |
Sep
(8) |
Oct
(29) |
Nov
(1) |
Dec
(21) |
2023 |
Jan
(19) |
Feb
(9) |
Mar
|
Apr
(10) |
May
(7) |
Jun
(10) |
Jul
(14) |
Aug
(17) |
Sep
(1) |
Oct
(9) |
Nov
(5) |
Dec
(14) |
2024 |
Jan
(12) |
Feb
(2) |
Mar
(8) |
Apr
(1) |
May
(6) |
Jun
(6) |
Jul
(24) |
Aug
(15) |
Sep
(1) |
Oct
(6) |
Nov
(20) |
Dec
(14) |
2025 |
Jan
(12) |
Feb
(2) |
Mar
(10) |
Apr
(11) |
May
(13) |
Jun
(1) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Krzysztof B. <kb...@un...> - 2023-04-20 09:22:37
|
Hi Sander, W dniu 18.04.2023 o 11:45, Sander Apweiler pisze: > Hi Krzysztof, > we got the feedback that users where not able to update their email > addresses because they are not validated. We are running unity 3.11.2. > The attribute is verifiableEmail type and self modifiable. The users > are able to enter new email address but when they save them the > attached error is shown. I would assume that a new verification email > send. We don't support such flow, it is pretty risky. Suggested flow is as follows: 1. user adds *another* email, next to the existing one. Confirmation is sent. 2. user confirms the new email address 3. then user can delete the old one This flow ensures that user won't lock herself out, i.e. land in a situation w/o any valid email (what may be a problem in many cases: notifications, system consistency, credential reset). Surely if the flow described above shall be supported, attribute type needs to accept at least 2 values. We can make this more flexible (e.g. have this validation configurable, or more sophisticated, taking into account also email identities of the user), but that would need development. Best, Krzysztof |
From: Sander A. <sa....@fz...> - 2023-04-19 05:51:42
|
Dear Krzysztof, we have in one upman managed group the problem that a NullPointer exception is raised if the user switched to invitations and tries to create a new one. I added the stack trace. Sadly I didn't see anything else in the log before, since we reduced the loglevel to see if the system has an issue with IO, which we can eliminate as cause for slow unity. 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 Stefan Müller Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Dr. Ir. Pieter Jansens, Prof. Dr. Astrid Lambrecht, Prof. Dr. Frauke Melchior ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
From: Sander A. <sa....@fz...> - 2023-04-18 10:05:11
|
Hi Krzysztof, we got the feedback that users where not able to update their email addresses because they are not validated. We are running unity 3.11.2. The attribute is verifiableEmail type and self modifiable. The users are able to enter new email address but when they save them the attached error is shown. I would assume that a new verification email send. 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 Stefan Müller Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Dr. Ir. Pieter Jansens, Prof. Dr. Astrid Lambrecht, Prof. Dr. Frauke Melchior ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
From: Krzysztof B. <kb...@un...> - 2023-02-10 17:37:34
|
W dniu 6.02.2023 o 10:59, Sander Apweiler pisze: > Hi Krzysztof, > I just pasted the part of the google registration form. Please let me > know if you want to have the full export. I saw that the full export is > not valid json. There is missing the closing ]. thx [CUT] > And it seems that the custom form layout is not applied, too. It is, although you have triggered one edge case where we can improve. The logic deciding whether a configured caption should be shown or not is not simple, as other elements of the layout can disappear at runtime (e.g. attribute may be provided by google, and not configured to be overwritten - then no component on form). So we are skipping some captions. And it seems we skip them bit too many cases, including your case when caption is the first element. We will improve this as a bugfix. while reworking on our registration forms, we recognized that the >>>> Form >>>> information, which we use to inform the users about the email >>>> validation, is not shown anymore in the form itself. We just see >>>> the >>>> boxes with identities and the policies. Is this a bug or intended >>>> behaviour? Seems as the case from our UY-1000 ticket - we don't support form information for the 2nd stage form, i.e. form shown after return from remote IdP in the case of remote registration. This ticket had wrong tags, and so was slightly forgotten. I've already fixed the tags and so is in the OSS requests queue. Best, Krzysztof |
From: Krzysztof B. <kb...@un...> - 2023-02-07 11:28:59
|
Hi Sander, W dniu 7.02.2023 o 09:26, Sander Apweiler pisze: > Dear Krzysztof, > we have problems with slow web UI and creashes of the endpoints. We got > a lot of feedback from users that the web UI is quite slow. Especially > if they want to invite multiple people or just accept an invitation > (more than two minutes the spinning wheel). > When we delete five registrations, the progress bar goes to ~95%, > blinks and it tokes two to three minutes to finish the deletion. If we > want to delete ten registrations, the risk is high that the console > endpoints crashes and we need to restart unity. > Switching the conflict resolution of an attribute statement from skip > to merge toke two minutes this morning. > > I'm pretty sure that our large number of users (14k+) is one of the > reasons for this. It seems that the server itself is not on load. It > has 0,3 having 4 cores. Unity is allowed to use 8GB RAM but the whole > server uses at the moment just 5,4GB. > > We increased already the number of workers to 32. Do you have some > hints how we can get a better performance? It is hard to say and most likely profiling will be needed to identify root cause. Before that can you be more specific by what do you mean be "endpoint crashes"? Are there any exceptions in logs? This might be very helpful. Generally there are many aspects influencing app performance. It is not only memory and CPU/threads. Also it might be related to I/O (e.g. excessive logging on DEBUG/TRACE level or RDBMS access - e.g. too few connections). There might be spikes in memory load which you won't observe wit OS tools, rather you need APM for that. What I'd anyway suggest for any bigger production instance. Then you will be able to check the detailed memory usage stats over time (if JVM runs close to its memory limits, GC kicks in and app starts to be very slow), threads utilization (there are few thread pools). In general my take on performance is that I first try to find reproducible case which is slow, then run it in some isolation (simulate on separate server or even on prod in off peak hours) with some extra logging turned on, find which operations are slow (gap in logs or long reported operation) and proceed from that point. HTH, Krzysztof |
From: Sander A. <sa....@fz...> - 2023-02-07 08:27:01
|
Dear Krzysztof, we have problems with slow web UI and creashes of the endpoints. We got a lot of feedback from users that the web UI is quite slow. Especially if they want to invite multiple people or just accept an invitation (more than two minutes the spinning wheel). When we delete five registrations, the progress bar goes to ~95%, blinks and it tokes two to three minutes to finish the deletion. If we want to delete ten registrations, the risk is high that the console endpoints crashes and we need to restart unity. Switching the conflict resolution of an attribute statement from skip to merge toke two minutes this morning. I'm pretty sure that our large number of users (14k+) is one of the reasons for this. It seems that the server itself is not on load. It has 0,3 having 4 cores. Unity is allowed to use 8GB RAM but the whole server uses at the moment just 5,4GB. We increased already the number of workers to 32. Do you have some hints how we can get a better performance? 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 Stefan Müller Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Dr. Ir. Pieter Jansens, Prof. Dr. Astrid Lambrecht, Prof. Dr. Frauke Melchior ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
From: Sander A. <sa....@fz...> - 2023-02-06 10:00:07
|
Hi Krzysztof, I just pasted the part of the google registration form. Please let me know if you want to have the full export. I saw that the full export is not valid json. There is missing the closing ]. Best regards, Sander On Mon, 2023-02-06 at 10:43 +0100, Krzysztof Benedyczak wrote: > Hi Sander, > > W dniu 3.02.2023 o 07:03, Sander Apweiler pisze: > > And it seems that the custom form layout is not applied, too. > > > > Best regards, > > Sander > > > > On Fri, 2023-02-03 at 06:56 +0100, Sander Apweiler wrote: > > > Good morning Krzysztof, > > > while reworking on our registration forms, we recognized that the > > > Form > > > information, which we use to inform the users about the email > > > validation, is not shown anymore in the form itself. We just see > > > the > > > boxes with identities and the policies. Is this a bug or intended > > > behaviour? > > Of course not intended. > > Can you share bit more of your config (perfectly: JSON export, which > you > can generate with REST API)? In general it works at our end pretty > well, > so would be great to be able to reproduce your issue - likely form > config specific. > > Thanks, > Krzysztof > > > > _______________________________________________ > Unity-idm-discuss mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss -- Federated Systems and Data Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Dr. Ir. Pieter Jansens, Prof. Dr. Astrid Lambrecht, Prof. Dr. Frauke Melchior ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
From: Krzysztof B. <kb...@un...> - 2023-02-06 09:44:14
|
Hi Sander, W dniu 3.02.2023 o 07:03, Sander Apweiler pisze: > And it seems that the custom form layout is not applied, too. > > Best regards, > Sander > > On Fri, 2023-02-03 at 06:56 +0100, Sander Apweiler wrote: >> Good morning Krzysztof, >> while reworking on our registration forms, we recognized that the >> Form >> information, which we use to inform the users about the email >> validation, is not shown anymore in the form itself. We just see the >> boxes with identities and the policies. Is this a bug or intended >> behaviour? Of course not intended. Can you share bit more of your config (perfectly: JSON export, which you can generate with REST API)? In general it works at our end pretty well, so would be great to be able to reproduce your issue - likely form config specific. Thanks, Krzysztof |
From: Sander A. <sa....@fz...> - 2023-02-03 06:03:38
|
And it seems that the custom form layout is not applied, too. Best regards, Sander On Fri, 2023-02-03 at 06:56 +0100, Sander Apweiler wrote: > Good morning Krzysztof, > while reworking on our registration forms, we recognized that the > Form > information, which we use to inform the users about the email > validation, is not shown anymore in the form itself. We just see the > boxes with identities and the policies. Is this a bug or intended > behaviour? > > Best regards, > Sander > > _______________________________________________ > Unity-idm-discuss mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss -- Federated Systems and Data Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Dr. Ir. Pieter Jansens, Prof. Dr. Astrid Lambrecht, Prof. Dr. Frauke Melchior ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
From: Sander A. <sa....@fz...> - 2023-02-03 05:57:14
|
Good morning Krzysztof, while reworking on our registration forms, we recognized that the Form information, which we use to inform the users about the email validation, is not shown anymore in the form itself. We just see the boxes with identities and the policies. Is this a bug or intended behaviour? 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 Stefan Müller Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Dr. Ir. Pieter Jansens, Prof. Dr. Astrid Lambrecht, Prof. Dr. Frauke Melchior ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
From: Sander A. <sa....@fz...> - 2023-02-02 10:49:45
|
Hi Krzysztof, sorry for the late answer. Last days were very busy. On Mon, 2023-01-30 at 09:35 +0100, Krzysztof Benedyczak wrote: > Hi Sander, > > First of all thank you for that email. We will internally talk about > it > more after the next release is out, but please find below some quick > comments. > > W dniu 25.01.2023 o 08:56, Sander Apweiler pisze: > > for the usage of MFA we want to provide some feedback. Some of this > > things you already know. > > > > - If OTP is wrong I have to redo the whole authentication. This > > feels a > > little bit annoying. On other platforms you just have to reenter > > the > > OTP, but not username & password. > > Makes sense, though is more complex: this behavior makes sense for > OTP > and maybe SMS as second factor, but completely not if say hardware > token > (fido2) is used as second factor. But worth considering as credential > dependent behavior. Shouldn't be big deal to be implemented. Ok. I didn't had any time to test FIDO2. But I want to do. > > > - Signalling MFA usage to SPs in common ways. There are already > > some > > common ways to signal the usage of MFA usage to services. This are > > the > > AuthnContextClassRef in SAML and the acr claim in OIDC. It would be > > great if this is supported by unity, too. > > - Proxying the MFA information from upstream IdP. If the upstram > > IdP > > already enables MFA and send the usage to services, MFA at unity > > does > > not increase the security anymore. Especially it the second factor > > is > > the same OTP generator. So it would be greate if there is a way to > > transfer the information to the SPs of unity. I know we can build a > > workaround but as you already mentioned storing information in > > unity to > > session bound attributes is not the best way. > > - If the user enables MFA in unity but the upstream IdP already > > preformed MFA, is would be great if there is a way for admins to > > configure if unity performs MFA or not and just proxies the > > information. As mentioned before there is no benefit if the second > > factor is the same. > > All 3 points above are mostly clear and true - a missing > functionality > in Unity. > > > - Have an additional authentication flow policy "step_up" which > > does > > not fall back to never, if the user has no MFA configured, but just > > prohibits the operation/login. > > Here I'm not sure if I understand. Do you mean that user needs to > provide two factors and if has only one set up then the authN fails? > Isn't that possible today? We see "step_up" as something between required and never. This will be only triggered if the user want to perform a "sensitiv" operation at a connected service or within unity. To perform this operation the user is send back to authentication and must perform a more secured authentication using MFA. But this does not work if the policy switches back to never, if the user has no MFA configured. In this case, the user can not perform the step_up authentication and the authorization fails. Hopefully it is more clear now. > > > - Have different session lifetime for user who performed MFA. Since > > the > > MFA gives a better trust about the user account is not compromised, > > it > > would be nice if we can increase the session time for those user > > who > > authenticated with MFA. This would be a benefit for those, who are > > doing the additional step. > > Here I don't think this is a correct approach. What is the liking > between LoA and session lifetime? If any I'd say it is opposite: if > you > are strongly authenticated, then you may potentially gain access to > more > resources, and so your session should be shorter. But essentially I'd > say there should be no dependency here. In general I agree to you. Security is hard to combine with laziness or "comfort" to users. This was one requirement by the management. If you do not see this as a valid request, I'm fine. Best regards, Sander > > Thank you a lot, > 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 Stefan Müller Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Dr. Ir. Pieter Jansens, Prof. Dr. Astrid Lambrecht, Prof. Dr. Frauke Melchior ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
From: Krzysztof B. <kb...@un...> - 2023-02-01 12:30:04
|
Dear Subscribers, I'm happy to announce availability of a new Unity release. As always all relevant links are available at https://unity-idm.eu/releases/release-3-12-0/ The 3.12.0 release brings a new library for easier REST integration with Unity from Java, a new REST endpoint to manage projects and much more. REST Types API The biggest change in this release is introduction of a new Java module /unity-rest-api/. This module can be used by apps written in Java, which integrate with Unity REST API. This module offers a clean, simple to use set of immutable classes following builder pattern, allowing for easy preparation of REST requests as well as parsing of responses. All Unity REST Admin paths are covered. At the same time the other module /unity-types-api/ gets deprecated. It will be dropped in the release 4.0.0. Users of this module should consider migrating to the /unity-rest-api/ module. Note that REST API has not been changed – the new module offers only a new Java API making the REST integration easier on Java platform. SAML metadata handling of IdPs We have finally concluded our big effort to update SAML metadata handling. The previous releases covered more impacting part of authenticators. In this release we have aligned the IdP part. A user visible effect of this change is slightly reduced memory consumption in case of IdP endpoints configured from SAML metadata, as well as faster (re)loading of metadata. RPM packaging dropped Since we haven’t observed almost any download activity related to RPM packaging, we have decided to drop it. tar.gz bundle is now the only distribution format. Proxied OAuth token introspection Unity allows now for acting as a proxy to other OAuth servers when it comes to handling OAuth token introspection requests. To enable this feature the upstream OAuth Authorization Servers needs to be setup in Unity OAuth endpoint’s configuration. UpMan REST API A new type of endpoint was added: UpMan REST API. This API complements UpMan web interface, but is not its REST replacement functionality-wise. Instead the REST API allows for quick and easy management of projects themselves. Creation, removal and fundamental configuration of an UpMan project (like setting the initial manager) can be done effortlessly with the new REST interface. Policy documents REST API Unity Admin REST API was enhanced with support of Unity policy documents management. Also a new authorization role was added: policyDocumentsManager. Holder of this role has generally limited permissions as a regular user, but additionally can manage policy documents over the REST API. Other improvements * After typing a wrong password the Enter key binding is not lost anymore * Invitations are not loosing the >by invitation< status even after switching to enquiry mode * Invitation to upman with default settings do not allows for choosing arbitrary initial groups anymore * Null entries in trusted apps tab on home UI should not happen anymore * Missing logo do not causes upman loading to crash anymore Best regards, Krzysztof |
From: Roman K. <ro...@un...> - 2023-01-30 10:45:36
|
Good morning Sander, This is a bug on our side, we are working on this. Fix will be in the next release, which happens to be early this week. Sorry for inconvenience. Best regards, Roman pt., 27 sty 2023 o 08:02 Sander Apweiler <sa....@fz...> napisał(a): > Good morning Roman, > yes workaround fixed the problem, I'm afraid that i might have much > more groups, where it fails because normally we do not set the logo. > Also on this group we didn't set it. So yes it was empty or null. We > were not aware that the logo is mandatory. It would be great if you can > mark this some how, if you want to have it mandatory. And if this is > not a bug please list this as on changes in the versions updates, since > it was working in older versions without the logo. > > Best regards, > Sander > > On Thu, 2023-01-26 at 18:23 +0100, Roman Krysiński wrote: > > HI Sander, > > > > It seems the Logo URL in some group w/ configured delegation has > > incorrect value - set to null. > > As the workaround I think it would be sufficient to find the > > promenatic group and from the console update the Logo URL to > > something meaningful. > > It would be helpful to understand how this project has been created, > > do you happen to know? > > > > In the meantime we will investigate the problem. > > > > Please let me know if the workaround worked for you. > > > > Best, > > Roman > > > > czw., 26 sty 2023 o 13:36 Sander Apweiler <sa....@fz...> > > napisał(a): > > > Hi Krzysztof, > > > we have an issue with only one group in upman. The user just got > > > the > > > word "error" shown when they logged into upman. I just got the > > > attached > > > stacktrace but no further info in the log. From the stacktrace I > > > assume > > > that some config/parameter is missing but I don't know what. Do you > > > know where this exception is raised? > > > > > > 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 Stefan Müller > Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), > Karsten Beneke (stellv. Vorsitzender), Dr. Ir. Pieter Jansens, > Prof. Dr. Astrid Lambrecht, Prof. Dr. Frauke Melchior > ----------------------------------------------------------------------- > ----------------------------------------------------------------------- > > > > > > |
From: Krzysztof B. <kb...@un...> - 2023-01-30 08:35:57
|
Hi Sander, First of all thank you for that email. We will internally talk about it more after the next release is out, but please find below some quick comments. W dniu 25.01.2023 o 08:56, Sander Apweiler pisze: > for the usage of MFA we want to provide some feedback. Some of this > things you already know. > > - If OTP is wrong I have to redo the whole authentication. This feels a > little bit annoying. On other platforms you just have to reenter the > OTP, but not username & password. Makes sense, though is more complex: this behavior makes sense for OTP and maybe SMS as second factor, but completely not if say hardware token (fido2) is used as second factor. But worth considering as credential dependent behavior. Shouldn't be big deal to be implemented. > - Signalling MFA usage to SPs in common ways. There are already some > common ways to signal the usage of MFA usage to services. This are the > AuthnContextClassRef in SAML and the acr claim in OIDC. It would be > great if this is supported by unity, too. > - Proxying the MFA information from upstream IdP. If the upstram IdP > already enables MFA and send the usage to services, MFA at unity does > not increase the security anymore. Especially it the second factor is > the same OTP generator. So it would be greate if there is a way to > transfer the information to the SPs of unity. I know we can build a > workaround but as you already mentioned storing information in unity to > session bound attributes is not the best way. > - If the user enables MFA in unity but the upstream IdP already > preformed MFA, is would be great if there is a way for admins to > configure if unity performs MFA or not and just proxies the > information. As mentioned before there is no benefit if the second > factor is the same. All 3 points above are mostly clear and true - a missing functionality in Unity. > - Have an additional authentication flow policy "step_up" which does > not fall back to never, if the user has no MFA configured, but just > prohibits the operation/login. Here I'm not sure if I understand. Do you mean that user needs to provide two factors and if has only one set up then the authN fails? Isn't that possible today? > - Have different session lifetime for user who performed MFA. Since the > MFA gives a better trust about the user account is not compromised, it > would be nice if we can increase the session time for those user who > authenticated with MFA. This would be a benefit for those, who are > doing the additional step. Here I don't think this is a correct approach. What is the liking between LoA and session lifetime? If any I'd say it is opposite: if you are strongly authenticated, then you may potentially gain access to more resources, and so your session should be shorter. But essentially I'd say there should be no dependency here. Thank you a lot, Krzysztof |
From: Sander A. <sa....@fz...> - 2023-01-27 07:03:00
|
Good morning Roman, yes workaround fixed the problem, I'm afraid that i might have much more groups, where it fails because normally we do not set the logo. Also on this group we didn't set it. So yes it was empty or null. We were not aware that the logo is mandatory. It would be great if you can mark this some how, if you want to have it mandatory. And if this is not a bug please list this as on changes in the versions updates, since it was working in older versions without the logo. Best regards, Sander On Thu, 2023-01-26 at 18:23 +0100, Roman Krysiński wrote: > HI Sander, > > It seems the Logo URL in some group w/ configured delegation has > incorrect value - set to null. > As the workaround I think it would be sufficient to find the > promenatic group and from the console update the Logo URL to > something meaningful. > It would be helpful to understand how this project has been created, > do you happen to know? > > In the meantime we will investigate the problem. > > Please let me know if the workaround worked for you. > > Best, > Roman > > czw., 26 sty 2023 o 13:36 Sander Apweiler <sa....@fz...> > napisał(a): > > Hi Krzysztof, > > we have an issue with only one group in upman. The user just got > > the > > word "error" shown when they logged into upman. I just got the > > attached > > stacktrace but no further info in the log. From the stacktrace I > > assume > > that some config/parameter is missing but I don't know what. Do you > > know where this exception is raised? > > > > 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 Stefan Müller Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Dr. Ir. Pieter Jansens, Prof. Dr. Astrid Lambrecht, Prof. Dr. Frauke Melchior ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
From: Roman K. <ro...@un...> - 2023-01-26 17:24:05
|
HI Sander, It seems the Logo URL in some group w/ configured delegation has incorrect value - set to null. As the workaround I think it would be sufficient to find the promenatic group and from the console update the Logo URL to something meaningful. It would be helpful to understand how this project has been created, do you happen to know? In the meantime we will investigate the problem. Please let me know if the workaround worked for you. Best, Roman czw., 26 sty 2023 o 13:36 Sander Apweiler <sa....@fz...> napisał(a): > Hi Krzysztof, > we have an issue with only one group in upman. The user just got the > word "error" shown when they logged into upman. I just got the attached > stacktrace but no further info in the log. From the stacktrace I assume > that some config/parameter is missing but I don't know what. Do you > know where this exception is raised? > > 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 Stefan Müller > Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), > Karsten Beneke (stellv. Vorsitzender), Dr. Ir. Pieter Jansens, > Prof. Dr. Astrid Lambrecht, Prof. Dr. Frauke Melchior > ----------------------------------------------------------------------- > ----------------------------------------------------------------------- > > > > > > _______________________________________________ > Unity-idm-discuss mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss > |
From: Sander A. <sa....@fz...> - 2023-01-26 12:37:13
|
Hi Krzysztof, we have an issue with only one group in upman. The user just got the word "error" shown when they logged into upman. I just got the attached stacktrace but no further info in the log. From the stacktrace I assume that some config/parameter is missing but I don't know what. Do you know where this exception is raised? 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 Stefan Müller Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Dr. Ir. Pieter Jansens, Prof. Dr. Astrid Lambrecht, Prof. Dr. Frauke Melchior ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
From: Sander A. <sa....@fz...> - 2023-01-25 07:56:34
|
Hi Krzysztof, for the usage of MFA we want to provide some feedback. Some of this things you already know. - If OTP is wrong I have to redo the whole authentication. This feels a little bit annoying. On other platforms you just have to reenter the OTP, but not username & password. - Signalling MFA usage to SPs in common ways. There are already some common ways to signal the usage of MFA usage to services. This are the AuthnContextClassRef in SAML and the acr claim in OIDC. It would be great if this is supported by unity, too. - Proxying the MFA information from upstream IdP. If the upstram IdP already enables MFA and send the usage to services, MFA at unity does not increase the security anymore. Especially it the second factor is the same OTP generator. So it would be greate if there is a way to transfer the information to the SPs of unity. I know we can build a workaround but as you already mentioned storing information in unity to session bound attributes is not the best way. - If the user enables MFA in unity but the upstream IdP already preformed MFA, is would be great if there is a way for admins to configure if unity performs MFA or not and just proxies the information. As mentioned before there is no benefit if the second factor is the same. - Have an additional authentication flow policy "step_up" which does not fall back to never, if the user has no MFA configured, but just prohibits the operation/login. - Have different session lifetime for user who performed MFA. Since the MFA gives a better trust about the user account is not compromised, it would be nice if we can increase the session time for those user who authenticated with MFA. This would be a benefit for those, who are doing the additional step. I know some of them are not easy or fast solvable, but I hope all are doable in the future. What do you think about these points? Please let me know if some of them are unclear. Best regars, 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 Stefan Müller Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Dr. Ir. Pieter Jansens, Prof. Dr. Astrid Lambrecht, Prof. Dr. Frauke Melchior ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
From: Krzysztof B. <kb...@un...> - 2023-01-24 08:51:39
|
W dniu 23.01.2023 o 08:59, Sander Apweiler pisze: > Good morning Krzysztof, > my email stocked in the drafts folder ... > > So the sys:oauth:clientName is stored in /oauth-clients and is set for > this client. The attribute of setting the display name is not set to > all oauth clients, which does not seem to be an issue for other > clients. Thanks, we found one bug in this area, it is likely that it was a root cause of your problem. Will be fixed in the next release, we will see if it helps. Best, Krzysztof |
From: Sander A. <sa....@fz...> - 2023-01-23 08:00:09
|
Good morning Krzysztof, my email stocked in the drafts folder ... So the sys:oauth:clientName is stored in /oauth-clients and is set for this client. The attribute of setting the display name is not set to all oauth clients, which does not seem to be an issue for other clients. Best regards, Sander On Fri, 2023-01-20 at 18:27 +0100, Krzysztof Benedyczak wrote: > Hi Sander, > > W dniu 13.01.2023 o 09:43, Sander Apweiler pisze: > > Good morning Krzysztof, > > in this case it was OAuth. I will check if the attributes were set > > correctly. > > > Have you by chance identified the source of the problem? We are so > far > only able to reproduce this behavior when setting client name > attribute > to literal "null null" value. Still investigating, but wanted to hear > whether you have any new insights here? > > Thanks, > Krzysztof > -- Federated Systems and Data Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Volker Rieke Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Astrid Lambrecht, Prof. Dr. Frauke Melchior ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
From: Krzysztof B. <kb...@un...> - 2023-01-20 17:27:24
|
Hi Sander, W dniu 13.01.2023 o 09:43, Sander Apweiler pisze: > Good morning Krzysztof, > in this case it was OAuth. I will check if the attributes were set > correctly. > Have you by chance identified the source of the problem? We are so far only able to reproduce this behavior when setting client name attribute to literal "null null" value. Still investigating, but wanted to hear whether you have any new insights here? Thanks, Krzysztof |
From: Sander A. <sa....@fz...> - 2023-01-13 08:43:49
|
Good morning Krzysztof, in this case it was OAuth. I will check if the attributes were set correctly. Best regards, Sander On Fri, 2023-01-13 at 09:36 +0100, Krzysztof Benedyczak wrote: > Hi Sander, > > W dniu 12.01.2023 o 17:02, Sander Apweiler pisze: > > Hi Krzysztof, > > > > we got some tickets that our instance show in the > > trustedApplications > > module services with the name null null (see screenshot). Which > > attribute does the module use to display the name? > > > That depends on the type of application. In case of SAML SPs it is > not > in attribute, it is taken from metadata. > > In case of OAuth it is in general taken from sys:oauth:clientName (in > proper group with IdP's OAuth clients) or from '/' attribute used as > displayedName (by default 'name'). > > Anyway nulls should not be shown. Can you please give any hint on > what > is inside those blocked entries? Would be very helpful to know at > least > whether those were SAML or OAuth apps. > > Best, > Krzysztof > > -- Federated Systems and Data Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Volker Rieke Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Astrid Lambrecht, Prof. Dr. Frauke Melchior ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
From: Krzysztof B. <kb...@un...> - 2023-01-13 08:37:10
|
Hi Sander, W dniu 12.01.2023 o 17:02, Sander Apweiler pisze: > Hi Krzysztof, > > we got some tickets that our instance show in the trustedApplications > module services with the name null null (see screenshot). Which > attribute does the module use to display the name? > That depends on the type of application. In case of SAML SPs it is not in attribute, it is taken from metadata. In case of OAuth it is in general taken from sys:oauth:clientName (in proper group with IdP's OAuth clients) or from '/' attribute used as displayedName (by default 'name'). Anyway nulls should not be shown. Can you please give any hint on what is inside those blocked entries? Would be very helpful to know at least whether those were SAML or OAuth apps. Best, Krzysztof |
From: Sander A. <sa....@fz...> - 2023-01-12 16:02:46
|
Hi Krzysztof, we got some tickets that our instance show in the trustedApplications module services with the name null null (see screenshot). Which attribute does the module use to display the name? 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. Astrid Lambrecht, Prof. Dr. Frauke Melchior ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
From: Krzysztof B. <kb...@un...> - 2023-01-05 10:53:53
|
Hi Sander, W dniu 3.01.2023 o 15:14, Sander Apweiler pisze: > Hi Krzysztof, > > On Tue, 2023-01-03 at 14:54 +0100, Krzysztof Benedyczak wrote: >> Hi Sander, >> >> W dniu 3.01.2023 o 07:39, Sander Apweiler pisze: >>> Dear Krzysztof, >>> first of all happy new year and all the best for 2023. >>> >>> After enabling two factor authentication on our services, we want >>> to >>> signal the usage of it to the services. In SAML we want to use the >>> https://refeds.org/profile/mfa in AuthnContextClassRef. In OIDC we >>> want >>> to use the acr claim. Is this possible within unity? I didn't find >>> anything in the manual about setting AuthnContextClassRef or acr. >> Unfortunately neither acr nor amr are not implemented in Unity as of >> now. Same for SAML. >> >>> The second thing we are thinking about is proxying the information >>> from >>> the Upstream IdPs if there was 2FA used. I read that we can read >>> the >>> AuthnContextClassRef in SAML input translation profile. >> Yes, it is exposed as an attribute in the context. >> >> >>> Is there also >>> an action which removes the old value, if this is not covered in >>> the >>> next login anymore? >> Hm, I don't understand the question. In general I don't think it is >> possible to set AuthnContextClassRef in SAML response manually. It >> should be possible to set manually acr in output profile for OAuth >> AS, >> although with some some extra work (i.e. one would need to put that >> in >> output profile + add to some scope, like profile). > Let me try to explain it. When I store the value of the > AuthnContextClassRef from remote IdP on an attribute and it signals > that 2FA was used but the next login the AuthnContextClassRef is not > released by the IdP anymore, I can not use the old value anymore and > must assume that no 2FA was performed. Of course I can create some > complex MVEL expression, but maybe there is an easier was to drop the > old information if the AuthnContextClassRef is not send by the remote > IdP anymore. I would just overwrite the attribute each time setting it to what was provided or to some default value otherwise. However, please keep in mind that, as we discussed long time ago, this is a generally imperfect workaround. Correctly, information on authentication context (from upstream IdP) should not be kept in an attribute but should be bound to login session and should be set there correctly on each authentication. This is very important if a given user can login both with remote IdP and with some local credential: in such case attribute storing authnContext from IdP will be there also after login with the local credential. So in general that's a bigger missing feature. Best, Krzysztof |