Menu
▾
▴
unity-idm-discuss — Unity discussion and support
You can subscribe to this list here.
| 2014 |
Jan
(3) |
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(2) |
Aug
(2) |
Sep
|
Oct
(3) |
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2015 |
Jan
(20) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
(15) |
Jul
(1) |
Aug
(7) |
Sep
(13) |
Oct
(2) |
Nov
(10) |
Dec
(1) |
| 2016 |
Jan
|
Feb
(2) |
Mar
|
Apr
(2) |
May
(1) |
Jun
|
Jul
(1) |
Aug
(2) |
Sep
(11) |
Oct
(7) |
Nov
(6) |
Dec
(11) |
| 2017 |
Jan
(10) |
Feb
(5) |
Mar
(27) |
Apr
(34) |
May
(25) |
Jun
(14) |
Jul
(7) |
Aug
(17) |
Sep
(11) |
Oct
(6) |
Nov
(14) |
Dec
(10) |
| 2018 |
Jan
(8) |
Feb
(19) |
Mar
(40) |
Apr
(9) |
May
(16) |
Jun
(23) |
Jul
(31) |
Aug
(7) |
Sep
(9) |
Oct
(6) |
Nov
(14) |
Dec
(19) |
| 2019 |
Jan
(4) |
Feb
(6) |
Mar
(1) |
Apr
(2) |
May
(6) |
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(19) |
Dec
(14) |
| 2020 |
Jan
(10) |
Feb
(24) |
Mar
(49) |
Apr
(26) |
May
(12) |
Jun
(4) |
Jul
(13) |
Aug
(32) |
Sep
(13) |
Oct
(10) |
Nov
(4) |
Dec
(16) |
| 2021 |
Jan
(2) |
Feb
(8) |
Mar
(15) |
Apr
(19) |
May
(5) |
Jun
(13) |
Jul
(6) |
Aug
(38) |
Sep
(11) |
Oct
(18) |
Nov
(11) |
Dec
(13) |
| 2022 |
Jan
(10) |
Feb
(21) |
Mar
(28) |
Apr
(3) |
May
(7) |
Jun
(9) |
Jul
(14) |
Aug
(13) |
Sep
(8) |
Oct
(29) |
Nov
(1) |
Dec
(21) |
| 2023 |
Jan
(19) |
Feb
(9) |
Mar
|
Apr
(10) |
May
(7) |
Jun
(10) |
Jul
(14) |
Aug
(17) |
Sep
(1) |
Oct
(9) |
Nov
(5) |
Dec
(14) |
| 2024 |
Jan
(12) |
Feb
(2) |
Mar
(8) |
Apr
(1) |
May
(6) |
Jun
(6) |
Jul
(24) |
Aug
(15) |
Sep
(1) |
Oct
(6) |
Nov
(20) |
Dec
(14) |
| 2025 |
Jan
(12) |
Feb
(2) |
Mar
(10) |
Apr
(11) |
May
(13) |
Jun
(1) |
Jul
(2) |
Aug
(2) |
Sep
(8) |
Oct
(1) |
Nov
|
Dec
|
|
From: Krzysztof B. <kb...@un...> - 2020-04-21 21:12:44
|
Hi D, uff, a complex email :-) Let's start from a small terminology clarification, to ensure we are on the same page. In Unity there a certain situation which is called as "unknown remote user" flow. It is triggered when a user authenticates using external IdP, but after successful remote authentication, this user is not mapped (by means of input translation profile) onto _existing_ local entity. Example: user, after returning from external IdP, was mapped to 'username' identity with value 'awst', but there is no 'awst' present in Unity's DB. And now the remaining clarifications: 1. So in the "unknown remote user" flow you can either (a) put user into registration flow (which typically includes an interactive step of filling some form, but need not to) or (b) put user into account association flow where user has to link the unknown remote identity with some other existing locally account. So (b) is essentially when remote identity is auxiliary, an addition to a regular, mandatory local account. A rare case. Finally there is (c) - user can choose on her own whether to do (a) or (b). In practice (a) or (c) is used. 2. In order to trigger the "unknown remote user" flow, make sure _not to auto create_ a user using input profile. I.e. if you use in your profile mapIdentity action with CREATE_OR_MATCH, this flow will be never triggered, as profile will either match with the existing user or create a local account for the remote one and match to it. I guess this is your problem from "as a side note". 3. Unity has no feature to decide whether to start flow (a) or (b) or go to (c) at runtime. Which path is taken is a result of static configuration. I agree that we may have a feature here: we can allow admins to specify some rule to check whether there is a local user who looks _similar_ to the remote one, and basing on this similarity either suggest user identity linking, or skip it. However this is a very complex feature: similarity will be different between deployments, checking it may require full text searches with text distance metering support etc. Some will check by same email, some with name, some with pair of surname and first name, some will take into account institution etc. And even with all of this - what if the similarity check returns that there is no one similar, but user has a local account and wants to link with it? 4. Your particular case sounds for me as one example of the above: on one hand you want to ask user to link accounts if remote username matches local one. But on another you don't trust remote one. So can you guarantee that remote user "johnny" is not the same as previously registered local "j.smith"? I.e. there is not only a security precaution not to link automatically to take into account, but also a question why not to allow for linking when usernames do _not_ match. OK, so what you can do with Unity is: ignore whether remote username is the same as the local one, just treat remote username as remote 'identifier' typed identity, perhaps with some prefix as a namespace. Function of this identifier will be to match _returning_ remote users. Follow path (c), i.e. when unknown remote user flow is triggered (i.e. this will be when a given user logs into unity with remote identity for the very 1st time): allow the user to select whether to link account or register. If linking is chosen Unity will ask the user for authenticating with the local account (2nd authN for the user), after it accounts will be linked, login with either of them will be equivalent (well, subject to MFA settings, but typically). If user chooses to register then you can provide a registration form exactly as you envision: prefilled with remote data and also prompting for password setup. Does it work for you? Also note that there are also other options, much different. E.g. you can create a registration form, using remote credential. So you can guide users to register using remote identity. This is more typical path, as you can instruct user more clearly what happens, is more often used then the "unknown remote user flow", in which users have to try to authenticate even when they don't have any account/haven't access your service yet. This may be puzzling for some, who will search for "sign up" instead of trying to "sign in". Other option is to remove account linking from the flow, if this is a rare choice, and rather treat it as special case: two accounts can be also associated outside of login flow. I hope I clarified this at least a little bit, not other way round :-) Best, Krzysztof |
|
From: Sander A. <sa....@fz...> - 2020-04-21 06:30:11
|
Hi Krzysztof, I found the action "failAuthentication" in output translation profile which looks very promising to perform some light wight authorisation. The action itself works, but the error message is not displayed and I'm redirected to the SP. Is this flow wanted? I would expect that the entered error message is displayed to the user and the login flow is interrupted. Cheers, Sander -- Federated Systems and Data Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ---------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Volker Rieke Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: D B. <ba...@aw...> - 2020-04-17 16:49:11
|
Hi, from the manual I gather that unity supports quite complex scenarios for combining remote and local authentication - but I wasn't able to piece together from it how to configure what I need. I've got local users with username identities who authenticate with passwords. Now I'd like to add a remote SAML IDP with the following behaviour: 1. If a user tries remote authentication for a locally existing username for the first time, they are asked to associate those identities. This should prevent malicious users from hijacking existing local users' accounts by registering the same username at the remote IDP. 2. If a user tries remote authenticiation after association with a local account, they can just log in normally. 3. If a user tries remote authentication and the username doesn't exist locally, they are shown a pre-filled registration form (with the values obtained from the remote IDP) where they have to accept the terms and conditions. Admins are notified and can accept registrations. After acceptance, the local account is associated with the remote identity. 4. Local login with passwords for existing local users is still possible. Ideally, newly created remote users are able to set a password and thus have a 'local' account as well. I can't quite figure out how to do 1 and 3 yet. Re 1: How can I force association and not just let remote users in as soon as the usernames match? I suspect it has to do with the identity mapping in the input translation profile, described in http://www.unity-idm.eu/documentation/unity-3.2.1/manual.html#input-translation but I'm unclear if CREATE_OR_MATCH, MATCH, REQUIRE_MATCH, or UPDATE_OR_MATCH would be the correct value to chose. And what else is required to make it work. Re 3: In my remote saml authentication facility, I've set the registration form to an existing, public form that collects username and email 'From remote IdP and shown RO'. However, when testing I'm never presented with this registration form after remotely authenticating - seems I'm missing some option? As a side note: it seems account association can produce entities with multiple usernames. Both of those usernames will be sent to my SAML SPs - what's best practice here to avoid weird effects? Can I somehow tell unity to only send along the username that was created first? Or to import a new (remote) username only if the entity doesn't already have one? Cheers, D |
|
From: Krzysztof B. <kb...@un...> - 2020-04-16 18:20:33
|
Dear Subscribers,
A subsequent revision release 3.2.2 is available for download. This time
we don't have any major issues, just a bunch of smaller ones.
Besides bug fixes this release brings two small but helpful new features:
* We have improved debug logging around registration and remote
authentication flows, which can be helpful to diagnose problems with
complex configurations.
* Also it is possible to configure TLS protocol versions supported by
the server, without relying on proxy or JDK settings.
Details as always: https://www.unity-idm.eu/downloads/
Best,
Krzysztof
|
|
From: D B. <ba...@aw...> - 2020-04-16 13:02:07
|
Hi, thanks for confirming! Currently, I can't volunteer the necessary resources on my side, sorry. So we'll all wait and see ;-) D On 15/04/2020 14:49, Krzysztof Benedyczak wrote: > Hi, > > W dniu 14.04.2020 o 18:39, D Baum pisze: >> Hi, >> >> picking up a very old thread: What's the current status of LDAP >> endpoint(s) in unity? >> Is it possible to access unity entities through an LDAP endpoint? Or to >> automatically create LDAP entries for new entities? If so: how? >> (Note: I'm not talking about 'outsourcing' authentication to an LDAP >> server) > > Unfortunately I heard nothing in this topic more or less since that > time. In other words there is some beta-quality implementation laying > around in a branch. I can't commit to any stronger push from our team to > take this over, polish and merge, but we can help if there is some > volunteer. > > Best, > Krzysztof > |
|
From: Krzysztof B. <kb...@un...> - 2020-04-15 12:49:38
|
Hi, W dniu 14.04.2020 o 18:39, D Baum pisze: > Hi, > > picking up a very old thread: What's the current status of LDAP > endpoint(s) in unity? > Is it possible to access unity entities through an LDAP endpoint? Or to > automatically create LDAP entries for new entities? If so: how? > (Note: I'm not talking about 'outsourcing' authentication to an LDAP server) Unfortunately I heard nothing in this topic more or less since that time. In other words there is some beta-quality implementation laying around in a branch. I can't commit to any stronger push from our team to take this over, polish and merge, but we can help if there is some volunteer. Best, Krzysztof |
|
From: D B. <ba...@aw...> - 2020-04-14 16:44:28
|
Hi, picking up a very old thread: What's the current status of LDAP endpoint(s) in unity? Is it possible to access unity entities through an LDAP endpoint? Or to automatically create LDAP entries for new entities? If so: how? (Note: I'm not talking about 'outsourcing' authentication to an LDAP server) Cheers, D On 27/07/2018 11:29, Krzysztof Benedyczak wrote: > Hi Fabian, > > W dniu 26.07.2018 o 10:12, Fabian Mangels pisze: >> >> Hi list, >> >> Is it possible to integrate an LDAP endpoint in Unity? >> I would like to access the local entities in the Unity database via >> LDAP, so that even non-web-based services can use the stored entities >> in Unity. >> Or is there another workaround for such a project? >> Thanks in advance! > > We have a long-lasting effort to expose such functionality in Unity. > However it was still not integrated into baseline code as there are > quite a few issues with the code to be solved first. It is hard for me > to provide timeline for this - depends bit on Willem's help here. > > Alternatives are to use the proprietary REST-admin endpoint of Unity or > (even better) OAuth, which can be used without web too. > > Best > Krzysztof > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > Unity-idm-discuss mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss > |
|
From: D B. <ba...@aw...> - 2020-04-07 10:50:21
|
Hi, I've solved my immediate issue by manually creating saved credentials in Firefox (Preferences -> Privacy & Security) -> Saved Logins... -> Create New Login) It now prefills the login form like it should, so I'm suspecting it may be something in my Firefox config that prevents saving passwords. However, before that I've found some nice sources about optimising for password managers, maybe they are useful to you: https://hiddedevries.nl/en/blog/2018-01-13-making-password-managers-play-ball-with-your-login-form https://www.chromium.org/developers/design-documents/form-styles-that-chromium-understands I tried to test this out with the Inspect Element editor (adding various features to the HTML live) but unity then complains about missing inputs, so I guess I'd need to understand VAADIN and how the login forms are rendered before testing any further. Cheers, D On 06/04/2020 20:19, Krzysztof Benedyczak wrote: > Hi, > > W dniu 03.04.2020 o 11:14, D Baum pisze: >> Hi, >> >> I've got a feeling that the unit web login endpoint does something to >> prevent my Firefox from storing the login credentials - is that right? >> >> Is there an option to turn this off for testing purposes? Testing the >> login process and always re-entering the credentials is a bit of a >> pain... > > Nothing intentional here. I've noticed that FF has a problem with > capturing credentials. Chrome works fine and at least 1password from > commercial passs managers. I guess something is not suiting FF from > field metadata but I never got to particular HTML/CSS element that is > causing it. > > If you find what is that "something" let me know, may be easy to fix, > especially if this is CSS related. > > Best, > Krzysztof > |
|
From: Krzysztof B. <kb...@un...> - 2020-04-06 18:20:05
|
Hi, W dniu 03.04.2020 o 11:14, D Baum pisze: > Hi, > > I've got a feeling that the unit web login endpoint does something to > prevent my Firefox from storing the login credentials - is that right? > > Is there an option to turn this off for testing purposes? Testing the > login process and always re-entering the credentials is a bit of a pain... Nothing intentional here. I've noticed that FF has a problem with capturing credentials. Chrome works fine and at least 1password from commercial passs managers. I guess something is not suiting FF from field metadata but I never got to particular HTML/CSS element that is causing it. If you find what is that "something" let me know, may be easy to fix, especially if this is CSS related. Best, Krzysztof |
|
From: D B. <ba...@aw...> - 2020-04-03 09:14:23
|
Hi, I've got a feeling that the unit web login endpoint does something to prevent my Firefox from storing the login credentials - is that right? Is there an option to turn this off for testing purposes? Testing the login process and always re-entering the credentials is a bit of a pain... Cheers, D |
|
From: D B. <ba...@aw...> - 2020-04-02 14:39:31
|
On 02/04/2020 15:39, Krzysztof Benedyczak wrote: > well, if you don't have a personal certificate installed in your > browser's keystore, what is true for 99+% users then you won't be bugged > by the browser (with exception of Safari AFAIR). So that's not that bad > in general. But true we can think about changing the default, it used to > be more needed in the past. Especially as TLS authN is passing away with > FIDO2/WebAuthn. This seems to be happening in both Safari and Chrome on Macs but not in Firefox. Didn't happen in my Linux Firefox. I haven't tested with Chrome anywhere else. Now that I know about the setting, I'm not to bothered by the issue but for someone doing a fresh install this might come quite unexpected. |
|
From: Krzysztof B. <kb...@un...> - 2020-04-02 13:39:41
|
W dniu 02.04.2020 o 15:30, D Baum pisze: > Yes, that's it, thanks a lot! > > What's with this default setting? This sounds unusual. Is the normal > unity usecase for internal authentication where all clients have a cert > installed? > well, if you don't have a personal certificate installed in your browser's keystore, what is true for 99+% users then you won't be bugged by the browser (with exception of Safari AFAIR). So that's not that bad in general. But true we can think about changing the default, it used to be more needed in the past. Especially as TLS authN is passing away with FIDO2/WebAuthn. |
|
From: D B. <ba...@aw...> - 2020-04-02 13:30:26
|
Yes, that's it, thanks a lot! What's with this default setting? This sounds unusual. Is the normal unity usecase for internal authentication where all clients have a cert installed? Cheers, D On 02/04/2020 13:39, Sander Apweiler wrote: > Hi D, > did you set unityServer.core.httpServer.wantClientAuthn to false? By > default it is true and requests a client certificate during the > handshake. > > Cheers, > Sander > > > On Thu, 2020-04-02 at 13:36 +0200, D Baum wrote: >> Hi, >> >> I've deactivated the 'cert' credential where I could find it in the >> config and GUI but unity keeps asking my users for a client >> certificate >> (on login). >> It happens only in Safari and Chrome, not in Firefox, apparently. >> >> Any tips on how to resolve this? >> >> Cheers, >> D >> >> >> _______________________________________________ >> Unity-idm-discuss mailing list >> Uni...@li... >> https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss |
|
From: Sander A. <sa....@fz...> - 2020-04-02 11:39:59
|
Hi D, did you set unityServer.core.httpServer.wantClientAuthn to false? By default it is true and requests a client certificate during the handshake. Cheers, Sander On Thu, 2020-04-02 at 13:36 +0200, D Baum wrote: > Hi, > > I've deactivated the 'cert' credential where I could find it in the > config and GUI but unity keeps asking my users for a client > certificate > (on login). > It happens only in Safari and Chrome, not in Firefox, apparently. > > Any tips on how to resolve this? > > Cheers, > D > > > _______________________________________________ > 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 Volker Rieke Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: D B. <ba...@aw...> - 2020-04-02 11:36:40
|
Hi, I've deactivated the 'cert' credential where I could find it in the config and GUI but unity keeps asking my users for a client certificate (on login). It happens only in Safari and Chrome, not in Firefox, apparently. Any tips on how to resolve this? Cheers, D |
|
From: Krzysztof B. <kb...@un...> - 2020-04-02 10:30:39
|
W dniu 01.04.2020 o 10:57, Sander Apweiler pisze: > Hi Krzysztof, > > at the moment we are using different versions of unity: 2.8.2, 3.2.0 > Java version: openjdk version "1.8.0_161" > OK, so I after some checking (was not so easy as our instances are mostly behind proxies) it seems that it depends :-) On quite a few things like JVM version, settings, ciphersuites etc. Jetty officially has documented that TLS 1.0 and 1.1 are disabled by default but it seems not to be the case always in practice. So to simplify the landscape, in the version 3.2.2 there will be a new option allowing to disable specific protocol versions allowed by the Unity's HTTPS server, regardless of the JVM settings. What is more in 3.3.0 the TLS 1.1 and 1.0 will be disabled *by default*. Cheers, Krzysztof |
|
From: Sander A. <sa....@fz...> - 2020-04-01 08:57:57
|
Hi Krzysztof, at the moment we are using different versions of unity: 2.8.2, 3.2.0 Java version: openjdk version "1.8.0_161" Cheers, Sander On Wed, 2020-04-01 at 10:53 +0200, Krzysztof Benedyczak wrote: > Hi Sander, > > W dniu 01.04.2020 o 09:57, Sander Apweiler pisze: > > Hi Krzysztof, > > > > is it possible to disable specific TLS versions (1.0 and 1.1)? I > > found > > only the unityServer.core.httpServer.disabledCipherSuites parameter > > we > > already use for a list of outdated cipher suits. > > > Which Unity version and which Java version you use? > > KB > > -- Federated Systems and Data Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ---------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Volker Rieke Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Krzysztof B. <kb...@un...> - 2020-04-01 08:53:20
|
Hi Sander, W dniu 01.04.2020 o 09:57, Sander Apweiler pisze: > Hi Krzysztof, > > is it possible to disable specific TLS versions (1.0 and 1.1)? I found > only the unityServer.core.httpServer.disabledCipherSuites parameter we > already use for a list of outdated cipher suits. > Which Unity version and which Java version you use? KB |
|
From: Marcus H. <ha...@ki...> - 2020-04-01 08:31:48
|
Are you referring to the "B" from here: https://www.ssllabs.com/ssltest/analyze.html?d=login.helmholtz-data-federation.de M. On 04/01/20 09:57, Sander Apweiler wrote: > Hi Krzysztof, > > is it possible to disable specific TLS versions (1.0 and 1.1)? I found > only the unityServer.core.httpServer.disabledCipherSuites parameter we > already use for a list of outdated cipher suits. > > Cheers, > Sander > -- > Federated Systems and Data > Juelich Supercomputing Centre > > phone: +49 2461 61 8847 > fax: +49 2461 61 6656 > email: sa....@fz... > > ---------------------------------------------------------------------- > ----------------------------------------------------------------------- > Forschungszentrum Juelich GmbH > 52425 Juelich > Sitz der Gesellschaft: Juelich > Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 > Vorsitzender des Aufsichtsrats: MinDir Volker Rieke > Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), > Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt > ----------------------------------------------------------------------- > ----------------------------------------------------------------------- > _______________________________________________ > Unity-idm-discuss mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss -- Marcus. |
|
From: Sander A. <sa....@fz...> - 2020-04-01 07:58:25
|
Hi Krzysztof, is it possible to disable specific TLS versions (1.0 and 1.1)? I found only the unityServer.core.httpServer.disabledCipherSuites parameter we already use for a list of outdated cipher suits. Cheers, Sander -- Federated Systems and Data Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ---------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Volker Rieke Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Krzysztof B. <kb...@un...> - 2020-03-28 22:16:32
|
Hi Sander, W dniu 14.03.2020 o 10:30, Krzysztof Benedyczak pisze: > Hi Sander, > > W dniu 11.03.2020 o 12:05, Sander Apweiler pisze: >> Hi Krzysztof, >> >> this is still an issue for us and users asked for some updates. How is >> your plan with the RO-user? Good news, I was completely wrong here. When I tried to check how difficult it is to implement, I've discovered that... this feature is available. Just set the "Anonymous user" role to your oauth client. It is exactly what you need: a fully read only user, who can not modify even its own credential. We should change the name of this role to "Read only user" eventually... Cheers, Krzysztof |
|
From: Sander A. <sa....@fz...> - 2020-03-26 08:20:55
|
Hi Krzysztof,
the issue is solved. After a hint from Tim I found the problem. Python
entered the values as string and not as an array. Now it works.
Cheers,
Sander
On Wed, 2020-03-25 at 17:39 +0100, Sander Apweiler wrote:
> Hi Krzysztof,
>
> I try to set a multivalue attribute using the rest API, but every
> time
> the content is stored in one value. The attribute is configured as
> multivalue attribute.
>
> First I tried to add the value element multiple times within the
> values
> array. This was my payload:
> {\'values\': [\'{"value":"
> http://localhost:4242","tags":[]},{"value":"http://localhost:8080","tags":[]},{"value":"http://localhost:43985","tags":[]}\'
> ], \'name\': \'sys:oauth:allowedReturnURI\', \'groupPath\': \'/\'}
> which lead to the value: {"value":"
> http://localhost:4242","tags":[]},{"value":"http://localhost:8080","tags":[]},{"value":"http://localhost:43985","tags":[]
> }
>
> So I removed the parts from the request which are wrong in the
> attribute and I tried with this payload:
> {\'values\': [\'"
> http://localhost:4242","http://localhost:8080","http://localhost:43985"\'
> ], \'name\': \'sys:oauth:allowedReturnURI\', \'groupPath\': \'/\'}
> which lead to the value "
> http://localhost:4242","http://localhost:8080","http://localhost:43985
> "
>
> After having a look in the Get response, I tried with this payload:
> {\'values\': [\'"
> http://localhost:4242",\\n"http://localhost:8080",\\n"http://localhost:43985"\'
> ], \'name\': \'sys:oauth:allowedReturnURI\', \'groupPath\': \'/\'}
> which lead to the value:
> "http://localhost:4242",
> "http://localhost:8080",
> "http://localhost:43985"
>
> I tried calling the API multiple time, but this changes only the
> value.
> This is fine, because it should be possible to update the existing
> value.
>
> Can you give me a hint how to set multivalues using the rest API?
>
> Best regards,
> Sander
--
Federated Systems and Data
Juelich Supercomputing Centre
phone: +49 2461 61 8847
fax: +49 2461 61 6656
email: sa....@fz...
----------------------------------------------------------------------
-----------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Volker Rieke
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
-----------------------------------------------------------------------
-----------------------------------------------------------------------
|
|
From: Sander A. <sa....@fz...> - 2020-03-25 16:39:23
|
Hi Krzysztof,
I try to set a multivalue attribute using the rest API, but every time
the content is stored in one value. The attribute is configured as
multivalue attribute.
First I tried to add the value element multiple times within the values
array. This was my payload:
{\'values\': [\'{"value":"http://localhost:4242","tags":[]},{"value":"http://localhost:8080","tags":[]},{"value":"http://localhost:43985","tags":[]}\'], \'name\': \'sys:oauth:allowedReturnURI\', \'groupPath\': \'/\'}
which lead to the value: {"value":"http://localhost:4242","tags":[]},{"value":"http://localhost:8080","tags":[]},{"value":"http://localhost:43985","tags":[]}
So I removed the parts from the request which are wrong in the
attribute and I tried with this payload:
{\'values\': [\'"http://localhost:4242","http://localhost:8080","http://localhost:43985"\'], \'name\': \'sys:oauth:allowedReturnURI\', \'groupPath\': \'/\'}
which lead to the value "http://localhost:4242","http://localhost:8080","http://localhost:43985"
After having a look in the Get response, I tried with this payload:
{\'values\': [\'"http://localhost:4242",\\n"http://localhost:8080",\\n"http://localhost:43985"\'], \'name\': \'sys:oauth:allowedReturnURI\', \'groupPath\': \'/\'}
which lead to the value:
"http://localhost:4242",
"http://localhost:8080",
"http://localhost:43985"
I tried calling the API multiple time, but this changes only the value.
This is fine, because it should be possible to update the existing
value.
Can you give me a hint how to set multivalues using the rest API?
Best regards,
Sander
--
Federated Systems and Data
Juelich Supercomputing Centre
phone: +49 2461 61 8847
fax: +49 2461 61 6656
email: sa....@fz...
----------------------------------------------------------------------
-----------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Volker Rieke
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
-----------------------------------------------------------------------
-----------------------------------------------------------------------
|
|
From: Krzysztof B. <kb...@un...> - 2020-03-25 09:43:17
|
Hi, W dniu 24.03.2020 o 17:08, D Baum pisze: > Hi! > > just found that on my unity instance I can register as separate entities > with userNames "dbaum", "DBaum", "DbAuM", etc. > > In itself, I find this a little confusing for the moderators/admins > (remembering that DBaum and dbaum can be different people). > > However, my unity clients don't all take capitalisation into account > when retrieving user data (see, e.g. > https://stackoverflow.com/questions/44821863/spring-boot-security-consider-case-insensitive-username-check-for-login/) > > I realise that this could be exploited to hijack a user's account if you > know the username, by registering the same username with different > capitalisation in unity and then logging into the client. > > Now, I've fixed this on the client side for my setup (where it should be > fixed). But can I ask that you consider adding a feature where users are > prevented from registering entities with usernames that differ from > existing ones only in capitalisation? Yes, makes sense. We have this supported since quite a long time for email identities (I guess more popular nowadays) but such feature can be also added for usernames. Cheers, Krzysztof |
|
From: Krzysztof B. <kb...@un...> - 2020-03-25 09:14:19
|
W dniu 24.03.2020 o 17:08, D Baum pisze: > Hi! > > just found that on my unity instance I can register as separate entities > with userNames "dbaum", "DBaum", "DbAuM", etc. > > In itself, I find this a little confusing for the moderators/admins > (remembering that DBaum and dbaum can be different people). > > However, my unity clients don't all take capitalisation into account > when retrieving user data (see, e.g. > https://stackoverflow.com/questions/44821863/spring-boot-security-consider-case-insensitive-username-check-for-login/) > > I realise that this could be exploited to hijack a user's account if you > know the username, by registering the same username with different > capitalisation in unity and then logging into the client. > > Now, I've fixed this on the client side for my setup (where it should be > fixed). But can I ask that you consider adding a feature where users are > prevented from registering entities with usernames that differ from > existing ones only in capitalisation? Just to clarify: we won't be able to just change the matching, what is technically trivial but may break many things: PAM based authN for instance or existing databases where there are already multiple usernames differing only with case. So this will be either a new identity type or an config option for username identity type. KB |
