Menu
▾
▴
unity-idm-discuss — Unity discussion and support
You can subscribe to this list here.
| 2014 |
Jan
(3) |
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(2) |
Aug
(2) |
Sep
|
Oct
(3) |
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2015 |
Jan
(20) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
(15) |
Jul
(1) |
Aug
(7) |
Sep
(13) |
Oct
(2) |
Nov
(10) |
Dec
(1) |
| 2016 |
Jan
|
Feb
(2) |
Mar
|
Apr
(2) |
May
(1) |
Jun
|
Jul
(1) |
Aug
(2) |
Sep
(11) |
Oct
(7) |
Nov
(6) |
Dec
(11) |
| 2017 |
Jan
(10) |
Feb
(5) |
Mar
(27) |
Apr
(34) |
May
(25) |
Jun
(14) |
Jul
(7) |
Aug
(17) |
Sep
(11) |
Oct
(6) |
Nov
(14) |
Dec
(10) |
| 2018 |
Jan
(8) |
Feb
(19) |
Mar
(40) |
Apr
(9) |
May
(16) |
Jun
(23) |
Jul
(31) |
Aug
(7) |
Sep
(9) |
Oct
(6) |
Nov
(14) |
Dec
(19) |
| 2019 |
Jan
(4) |
Feb
(6) |
Mar
(1) |
Apr
(2) |
May
(6) |
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(19) |
Dec
(14) |
| 2020 |
Jan
(10) |
Feb
(24) |
Mar
(49) |
Apr
(26) |
May
(12) |
Jun
(4) |
Jul
(13) |
Aug
(32) |
Sep
(13) |
Oct
(10) |
Nov
(4) |
Dec
(16) |
| 2021 |
Jan
(2) |
Feb
(8) |
Mar
(15) |
Apr
(19) |
May
(5) |
Jun
(13) |
Jul
(6) |
Aug
(38) |
Sep
(11) |
Oct
(18) |
Nov
(11) |
Dec
(13) |
| 2022 |
Jan
(10) |
Feb
(21) |
Mar
(28) |
Apr
(3) |
May
(7) |
Jun
(9) |
Jul
(14) |
Aug
(13) |
Sep
(8) |
Oct
(29) |
Nov
(1) |
Dec
(21) |
| 2023 |
Jan
(19) |
Feb
(9) |
Mar
|
Apr
(10) |
May
(7) |
Jun
(10) |
Jul
(14) |
Aug
(17) |
Sep
(1) |
Oct
(9) |
Nov
(5) |
Dec
(14) |
| 2024 |
Jan
(12) |
Feb
(2) |
Mar
(8) |
Apr
(1) |
May
(6) |
Jun
(6) |
Jul
(24) |
Aug
(15) |
Sep
(1) |
Oct
(6) |
Nov
(20) |
Dec
(14) |
| 2025 |
Jan
(12) |
Feb
(2) |
Mar
(10) |
Apr
(11) |
May
(13) |
Jun
(1) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Sander A. <sa....@fz...> - 2022-03-07 06:40:16
|
Good morning Krzysztof, we encountered a small problem if an invitation was send to another email address than the IdP provides. The switch to the login for existing users works fine, but we see only username/password input and not SAML/OIDC logins. I guess this is only a miss-configuration on out side. Can you give us a hint where we must perform the update? 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: Sander A. <sa....@fz...> - 2022-03-03 13:30:36
|
Hi Krzysztof, On Thu, 2022-03-03 at 14:01 +0100, Krzysztof Benedyczak wrote: > Hi, > > W dniu 03.03.2022 o 11:12, Sander Apweiler pisze: > > Hi Krzysztof, > > sorry for extending the question, but it is related to this. Would > > it > > possible to signal this in the ACR claim in OIDC and section in > > SAML? > > This might be the best way for services to use this information. I > > do > > not expect that this will work in the next release. > > After the simple enhancement as discussed so far adding the acr claim > should not be a big problem in output profile. That sounds great. > > As for SAML subject confirmations (or any dedicated support for ACRs > in > OIDC) - that's broader topic. We even have some old ticket about this > in > SAML context. Surely we would need to discuss requirements here. This > is > pretty fuzzy subject as number of standards, specs, and approaches > used > is very wide, and it is hard to design a solution working well for > (at > least) all the major use cases. No worry. We can this information pass via an attribute. Best regards, Sander > > Best, > Krzysztof > -- Federated Systems and Data Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Volker Rieke Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Astrid Lambrecht, Prof. Dr. Frauke Melchior ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Krzysztof B. <kb...@un...> - 2022-03-03 13:02:04
|
Hi, W dniu 03.03.2022 o 11:12, Sander Apweiler pisze: > Hi Krzysztof, > sorry for extending the question, but it is related to this. Would it > possible to signal this in the ACR claim in OIDC and section in SAML? > This might be the best way for services to use this information. I do > not expect that this will work in the next release. After the simple enhancement as discussed so far adding the acr claim should not be a big problem in output profile. As for SAML subject confirmations (or any dedicated support for ACRs in OIDC) - that's broader topic. We even have some old ticket about this in SAML context. Surely we would need to discuss requirements here. This is pretty fuzzy subject as number of standards, specs, and approaches used is very wide, and it is hard to design a solution working well for (at least) all the major use cases. Best, Krzysztof |
|
From: Sander A. <sa....@fz...> - 2022-03-03 10:12:18
|
Hi Krzysztof, sorry for extending the question, but it is related to this. Would it possible to signal this in the ACR claim in OIDC and section in SAML? This might be the best way for services to use this information. I do not expect that this will work in the next release. Best regards, Sander On Thu, 2022-03-03 at 09:03 +0100, Krzysztof Benedyczak wrote: > Hi, > > W dniu 02.03.2022 o 09:39, Sander Apweiler pisze: > > Good morning Krzysztof, > > > > On Tue, 2022-03-01 at 17:24 +0100, Krzysztof Benedyczak wrote: > > > hi, > > > > > > W dniu 01.03.2022 o 08:15, Sander Apweiler pisze: > > > > Good morning Krzysztof, > > > > good morning Roman, > > > > > > > > sorry for the next topic I open here. Hopefully it is easy to > > > > answer/solve. We are testing the 2FA using OTP. So far it works > > > > fine. > > > > But we are looking how we could signal a service that 2FA was > > > > used. > > > > Is > > > > there a way to get this information within unity? Maybe > > > > fetching > > > > the > > > > credentials status and if it is enabled for the user could > > > > help. > > > Unfortunately it is not exposed in output profile context. There > > > are > > > authenticated identities but no info about factors used to > > > authenticate. > > > Adding that is basically one line of code (maybe two - there are > > > two > > > factors) - so no problem to deliver that quickly. > > That would be great. In this case we could avoid having multiple > > Oauth > > or SAML one with mandatory 2FA and one with optional. > > No problem, I've opened a ticket to track that, should be in the next > feature release. > > 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: Sander A. <sa....@fz...> - 2022-03-03 08:09:48
|
Hi Krzysztof, great thanks! Best regards, Sander On Thu, 2022-03-03 at 09:03 +0100, Krzysztof Benedyczak wrote: > Hi, > > W dniu 02.03.2022 o 09:39, Sander Apweiler pisze: > > Good morning Krzysztof, > > > > On Tue, 2022-03-01 at 17:24 +0100, Krzysztof Benedyczak wrote: > > > hi, > > > > > > W dniu 01.03.2022 o 08:15, Sander Apweiler pisze: > > > > Good morning Krzysztof, > > > > good morning Roman, > > > > > > > > sorry for the next topic I open here. Hopefully it is easy to > > > > answer/solve. We are testing the 2FA using OTP. So far it works > > > > fine. > > > > But we are looking how we could signal a service that 2FA was > > > > used. > > > > Is > > > > there a way to get this information within unity? Maybe > > > > fetching > > > > the > > > > credentials status and if it is enabled for the user could > > > > help. > > > Unfortunately it is not exposed in output profile context. There > > > are > > > authenticated identities but no info about factors used to > > > authenticate. > > > Adding that is basically one line of code (maybe two - there are > > > two > > > factors) - so no problem to deliver that quickly. > > That would be great. In this case we could avoid having multiple > > Oauth > > or SAML one with mandatory 2FA and one with optional. > > No problem, I've opened a ticket to track that, should be in the next > feature release. > > 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...> - 2022-03-03 08:03:39
|
Hi, W dniu 02.03.2022 o 09:39, Sander Apweiler pisze: > Good morning Krzysztof, > > On Tue, 2022-03-01 at 17:24 +0100, Krzysztof Benedyczak wrote: >> hi, >> >> W dniu 01.03.2022 o 08:15, Sander Apweiler pisze: >>> Good morning Krzysztof, >>> good morning Roman, >>> >>> sorry for the next topic I open here. Hopefully it is easy to >>> answer/solve. We are testing the 2FA using OTP. So far it works >>> fine. >>> But we are looking how we could signal a service that 2FA was used. >>> Is >>> there a way to get this information within unity? Maybe fetching >>> the >>> credentials status and if it is enabled for the user could help. >> Unfortunately it is not exposed in output profile context. There are >> authenticated identities but no info about factors used to >> authenticate. >> Adding that is basically one line of code (maybe two - there are two >> factors) - so no problem to deliver that quickly. > That would be great. In this case we could avoid having multiple Oauth > or SAML one with mandatory 2FA and one with optional. No problem, I've opened a ticket to track that, should be in the next feature release. Best, Krzysztof |
|
From: Sander A. <sa....@fz...> - 2022-03-02 08:39:02
|
Good morning Krzysztof, On Tue, 2022-03-01 at 17:24 +0100, Krzysztof Benedyczak wrote: > hi, > > W dniu 01.03.2022 o 08:15, Sander Apweiler pisze: > > Good morning Krzysztof, > > good morning Roman, > > > > sorry for the next topic I open here. Hopefully it is easy to > > answer/solve. We are testing the 2FA using OTP. So far it works > > fine. > > But we are looking how we could signal a service that 2FA was used. > > Is > > there a way to get this information within unity? Maybe fetching > > the > > credentials status and if it is enabled for the user could help. > > Unfortunately it is not exposed in output profile context. There are > authenticated identities but no info about factors used to > authenticate. > Adding that is basically one line of code (maybe two - there are two > factors) - so no problem to deliver that quickly. That would be great. In this case we could avoid having multiple Oauth or SAML one with mandatory 2FA and one with optional. > > > Another question which might be raised y the user is, how could I > > delete the 2FA instead of disabling it. Is this possible? > > > We block this operation on HomeUI intentionally. It can be requested > via > admin (in console that's possible). In general that's very risky > (user > can lock herself out from service), and perhaps super rare operation. OK. I understand it fully. So we would just document that this operation must be requested via ticket. Best regards, Sander > > Best, > Krzysztof > > -- Federated Systems and Data Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Volker Rieke Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Astrid Lambrecht, Prof. Dr. Frauke Melchior ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Marcus H. <ha...@ki...> - 2022-03-02 08:25:48
|
[..] > > > > > Configuring per client is not acceptable as the same client may operate in > > > > > different contexts and in some it is using some dumb services which have a > > > > > limit on access token size. > > > > Yes. Fully agree. > > > > > So what are the proposals here? Use some proprietary request parameter for > > > > > it? > > > > I really don't know. If this is really about which scopes go into which > > > > place (JWT vs userinfo), then something proprietary might not be so > > > > harmful. I'm sure this question will bother others, too. > > > > > > > > > > > > One way out, could be to live with the long ATs. > > > > > > > > I'll check with our OIDC expert, but this won't turn around before monday. > > > > > > OK, let us know. > > > > > > If thinking about proprietary solution, I think we can have it. However I'd > > > keep it dead simple: just a flag "uy_put_claims_in_access_token", which > > > would put all claims in AT. > > He suggested using the same mechanism as in the "claims" place, but using > > a different keyword. > > > > He sends this reference: https://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter > > > > Maybe just calling it "claims_at" would be all it takes. > > > The claims parameter which in OIDC spec governs what should be put in id > token or user info fits nicely after adding claims_at. Agreed. But from > client side it is quite a complex parameter - you operate not on "all > claims", not on "claims related to scopes" but on individual claims. You > need to know them, there is no "*". Also this is complementary to claims > resulting from scopes, what dramatically increases complexity (e.g. asking > user to accepts some well defined scopes is easy, but about each individual > attribute/claim is not). > > It sounds to me 10x more complex than what you need. If so, then there must be some misunderstanding. I'm pretty sure I wanted to write `scopes_at` (but deep inside me I hate those oidc folks for tying the claims to scopes. I think I get the idea, but it's not so transparent). -- Marcus. |
|
From: Krzysztof B. <kb...@un...> - 2022-03-01 16:24:24
|
hi, W dniu 01.03.2022 o 08:15, Sander Apweiler pisze: > Good morning Krzysztof, > good morning Roman, > > sorry for the next topic I open here. Hopefully it is easy to > answer/solve. We are testing the 2FA using OTP. So far it works fine. > But we are looking how we could signal a service that 2FA was used. Is > there a way to get this information within unity? Maybe fetching the > credentials status and if it is enabled for the user could help. Unfortunately it is not exposed in output profile context. There are authenticated identities but no info about factors used to authenticate. Adding that is basically one line of code (maybe two - there are two factors) - so no problem to deliver that quickly. > Another question which might be raised y the user is, how could I > delete the 2FA instead of disabling it. Is this possible? > We block this operation on HomeUI intentionally. It can be requested via admin (in console that's possible). In general that's very risky (user can lock herself out from service), and perhaps super rare operation. Best, Krzysztof |
|
From: Krzysztof B. <kb...@un...> - 2022-03-01 16:06:55
|
Hi, W dniu 01.03.2022 o 09:46, Sander Apweiler pisze: > Good morning, > > a short addition. It is not only the oidc-agent witch has a problem > with the token size. EUDAT B2SAFE has it as well because they use the > token as password in iRODS and this has also limitations in size. > > And yes the most problems for switching the scopes would be for the > users of the oidc-agent. Because all other set them once. So maybe after all a proprietary request flag saying "add all claims to JWT AT"? Proprietary, but also dead simple and addressing your use cases in a direct way. Best, Krzysztof |
|
From: Krzysztof B. <kb...@un...> - 2022-03-01 16:05:23
|
Marcus, W dniu 28.02.2022 o 12:34, Marcus Hardt pisze: > On 28. Feb 2022 12:11, Krzysztof Benedyczak wrote: >> Hi Marcus, >> >> W dniu 23.02.2022 o 18:06, Marcus Hardt pisze: >>> Hi Krzysztof, >>> >>> >>> On 23. Feb 2022 16:08, Krzysztof Benedyczak wrote: >>>> Hi, >>>> >>>> I'm leaving the longer thread below for reference, however the main open >>>> point is how to specify what should land in JWT-style access token. >>>> I see no security implications here, so that's not a problem. >>>> >>>> From what you wrote configuring that via scopes is not great as would make >>>> it hard for the clients. >>> I'm not sure I understand. Requesting specific scopes is in the standard. >>> I understand that the problem is which claims go into jwt AT and which >>> ones are in the userinfo-endpoint, right? >> Requesting scopes is in the standard, that's no problem. But as I understood >> Sander (and also can imagine on my own) that's bit of an organizational >> problem. >> >> Let's assume Unity allows admin to configure per scope, whether attributes >> of that scope should go to AT or not. Now, if you have clients that require >> no extra claims in AT and some with opposite requirement, then you will need >> to create a duplicate of each scope in Unity: >> >> profile; profile_in_at >> >> job_info; job_info_in_at >> >> ... which will differ only with that setting. Clunky, both from server side >> and client side. > > Hmm. Another clarification (that isn't 100% clear, maybe): I think this > problem mostly relates to a single client-id: oidc-agent, as this is the > one used in many use-cases that involving delegation. > >> Also a small clarification: user-info endpoint will always return all >> claims. The only problem to decide is which claims also are put into JWT AT. > Ok; > > After thinking a bit, I think it might be best to keep both sets equal. > One (the main showstopper?) for AT<1K is our own application, and we do > have an inimplemented workaround. I think we'll have that done in like 4 > months (because there is more pressing stuff around). > >>>> Configuring per client is not acceptable as the same client may operate in >>>> different contexts and in some it is using some dumb services which have a >>>> limit on access token size. >>> Yes. Fully agree. >>>> So what are the proposals here? Use some proprietary request parameter for >>>> it? >>> I really don't know. If this is really about which scopes go into which >>> place (JWT vs userinfo), then something proprietary might not be so >>> harmful. I'm sure this question will bother others, too. >>> >>> >>> One way out, could be to live with the long ATs. >>> >>> I'll check with our OIDC expert, but this won't turn around before monday. >> >> OK, let us know. >> >> If thinking about proprietary solution, I think we can have it. However I'd >> keep it dead simple: just a flag "uy_put_claims_in_access_token", which >> would put all claims in AT. > He suggested using the same mechanism as in the "claims" place, but using > a different keyword. > > He sends this reference: https://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter > > Maybe just calling it "claims_at" would be all it takes. > The claims parameter which in OIDC spec governs what should be put in id token or user info fits nicely after adding claims_at. Agreed. But from client side it is quite a complex parameter - you operate not on "all claims", not on "claims related to scopes" but on individual claims. You need to know them, there is no "*". Also this is complementary to claims resulting from scopes, what dramatically increases complexity (e.g. asking user to accepts some well defined scopes is easy, but about each individual attribute/claim is not). It sounds to me 10x more complex than what you need. Best, Krzysztof |
|
From: Krzysztof B. <kb...@un...> - 2022-03-01 15:45:02
|
Hi Laura, W dniu 28.02.2022 o 12:57, Laura Hofer pisze: > Hello, > > we are currently trying to change our message management so that it is > handled locally through our configuration and not only through the web > UI. We noticed that we did not find in the documentation how the naming > of the individual messages works in the properties file. In this regard, > we also asked ourselves how we can create different messages of the same > message type. For example, if we want to send different RequestAccepted > messages for users from different areas. > > It would be great if you could help me with my questions. Let me explain that using this simple example: registrationRequestSubmitted.subject.en=New registration request registrationRequestSubmitted.consumer=RegistrationRequestSubmitted registrationRequestSubmitted.notificationChannel=default_email registrationRequestSubmitted.type=HTML registrationRequestSubmitted.bodyFile.en=msgTemplates/registrationRequestSubmitted.html In this example we are defining one message template with id 'registrationRequestSubmitted' (which you can freely choose). consumer defines the 'purpose' of the message, i.e. which Unity flow is using this type of template (and so defines its variables etc). In this case it is RegistrationRequestSubmitted so this message template can be used in registration forms as a template for sending notification about new registration request. body & subject can be in multiple localized variants (in the example in en, you can add .de variant you you want). Body value is just a path to a separate file with the content. type (HTML or PLAIN) defines whether this is plain text template of HTML one. Finally notification channel is one of available transports from Unity. default_email, default_sms are built-in, there is also an advanced option if you implemented your own code to send messages in Groovy (I can provide details if needed) - useful for integration with other mail systems (also allows for externalizing templates). To create 2 templates for the reg request accepted flow: registrationRequestAccepted1.subject.en=Registration request accepted registrationRequestAccepted1.consumer=RegistrationRequestAccepted registrationRequestAccepted1.notificationChannel=default_email registrationRequestAccepted1.type=HTML registrationRequestAccepted1.bodyFile.en=msgTemplates/registrationRequestAccepted-V1.html registrationRequestAccepted2.subject.en=Registration request accepted registrationRequestAccepted2.consumer=RegistrationRequestAccepted registrationRequestAccepted2.notificationChannel=default_email registrationRequestAccepted2.type=HTML registrationRequestAccepted2.bodyFile.en=msgTemplates/registrationRequestAccepted-V2.html We will need to add the above to the manual :-) HTH, Krzysztof |
|
From: Sander A. <sa....@fz...> - 2022-03-01 08:46:36
|
Good morning, a short addition. It is not only the oidc-agent witch has a problem with the token size. EUDAT B2SAFE has it as well because they use the token as password in iRODS and this has also limitations in size. And yes the most problems for switching the scopes would be for the users of the oidc-agent. Because all other set them once. Best regards, Sander On Mon, 2022-02-28 at 12:34 +0100, Marcus Hardt wrote: > On 28. Feb 2022 12:11, Krzysztof Benedyczak wrote: > > Hi Marcus, > > > > W dniu 23.02.2022 o 18:06, Marcus Hardt pisze: > > > Hi Krzysztof, > > > > > > > > > On 23. Feb 2022 16:08, Krzysztof Benedyczak wrote: > > > > Hi, > > > > > > > > I'm leaving the longer thread below for reference, however the > > > > main open > > > > point is how to specify what should land in JWT-style access > > > > token. > > > > I see no security implications here, so that's not a problem. > > > > > > > > From what you wrote configuring that via scopes is not great > > > > as would make > > > > it hard for the clients. > > > I'm not sure I understand. Requesting specific scopes is in the > > > standard. > > > I understand that the problem is which claims go into jwt AT and > > > which > > > ones are in the userinfo-endpoint, right? > > > > Requesting scopes is in the standard, that's no problem. But as I > > understood > > Sander (and also can imagine on my own) that's bit of an > > organizational > > problem. > > > > Let's assume Unity allows admin to configure per scope, whether > > attributes > > of that scope should go to AT or not. Now, if you have clients that > > require > > no extra claims in AT and some with opposite requirement, then you > > will need > > to create a duplicate of each scope in Unity: > > > > profile; profile_in_at > > > > job_info; job_info_in_at > > > > ... which will differ only with that setting. Clunky, both from > > server side > > and client side. > > Hmm. Another clarification (that isn't 100% clear, maybe): I think > this > problem mostly relates to a single client-id: oidc-agent, as this is > the > one used in many use-cases that involving delegation. > > > Also a small clarification: user-info endpoint will always return > > all > > claims. The only problem to decide is which claims also are put > > into JWT AT. > > Ok; > > After thinking a bit, I think it might be best to keep both sets > equal. > One (the main showstopper?) for AT<1K is our own application, and we > do > have an inimplemented workaround. I think we'll have that done in > like 4 > months (because there is more pressing stuff around). > > > > > Configuring per client is not acceptable as the same client may > > > > operate in > > > > different contexts and in some it is using some dumb services > > > > which have a > > > > limit on access token size. > > > Yes. Fully agree. > > > > So what are the proposals here? Use some proprietary request > > > > parameter for > > > > it? > > > I really don't know. If this is really about which scopes go into > > > which > > > place (JWT vs userinfo), then something proprietary might not be > > > so > > > harmful. I'm sure this question will bother others, too. > > > > > > > > > One way out, could be to live with the long ATs. > > > > > > I'll check with our OIDC expert, but this won't turn around > > > before monday. > > > > > > OK, let us know. > > > > If thinking about proprietary solution, I think we can have it. > > However I'd > > keep it dead simple: just a flag "uy_put_claims_in_access_token", > > which > > would put all claims in AT. > > He suggested using the same mechanism as in the "claims" place, but > using > a different keyword. > > He sends this reference: > https://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter > > Maybe just calling it "claims_at" would be all it takes. > -- 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: Sander A. <sa....@fz...> - 2022-03-01 07:15:13
|
Good morning Krzysztof, good morning Roman, sorry for the next topic I open here. Hopefully it is easy to answer/solve. We are testing the 2FA using OTP. So far it works fine. But we are looking how we could signal a service that 2FA was used. Is there a way to get this information within unity? Maybe fetching the credentials status and if it is enabled for the user could help. Another question which might be raised y the user is, how could I delete the 2FA instead of disabling it. Is this possible? 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: Laura H. <l....@fz...> - 2022-02-28 11:57:26
|
Hello, we are currently trying to change our message management so that it is handled locally through our configuration and not only through the web UI. We noticed that we did not find in the documentation how the naming of the individual messages works in the properties file. In this regard, we also asked ourselves how we can create different messages of the same message type. For example, if we want to send different RequestAccepted messages for users from different areas. It would be great if you could help me with my questions. Best regards, Laura Laura Hofer -- Juelich Supercomputing Centre Institute for Advanced Simulation Forschungszentrum Juelich GmbH 52425 Juelich, Germany E-Mail: l....@fz... Phone: +49 2461 61-6576 Fax: +49 2461 61-6656 ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ 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: Marcus H. <ha...@ki...> - 2022-02-28 11:35:03
|
On 28. Feb 2022 12:11, Krzysztof Benedyczak wrote: > Hi Marcus, > > W dniu 23.02.2022 o 18:06, Marcus Hardt pisze: > > Hi Krzysztof, > > > > > > On 23. Feb 2022 16:08, Krzysztof Benedyczak wrote: > > > Hi, > > > > > > I'm leaving the longer thread below for reference, however the main open > > > point is how to specify what should land in JWT-style access token. > > > I see no security implications here, so that's not a problem. > > > > > > From what you wrote configuring that via scopes is not great as would make > > > it hard for the clients. > > I'm not sure I understand. Requesting specific scopes is in the standard. > > I understand that the problem is which claims go into jwt AT and which > > ones are in the userinfo-endpoint, right? > > Requesting scopes is in the standard, that's no problem. But as I understood > Sander (and also can imagine on my own) that's bit of an organizational > problem. > > Let's assume Unity allows admin to configure per scope, whether attributes > of that scope should go to AT or not. Now, if you have clients that require > no extra claims in AT and some with opposite requirement, then you will need > to create a duplicate of each scope in Unity: > > profile; profile_in_at > > job_info; job_info_in_at > > ... which will differ only with that setting. Clunky, both from server side > and client side. Hmm. Another clarification (that isn't 100% clear, maybe): I think this problem mostly relates to a single client-id: oidc-agent, as this is the one used in many use-cases that involving delegation. > Also a small clarification: user-info endpoint will always return all > claims. The only problem to decide is which claims also are put into JWT AT. Ok; After thinking a bit, I think it might be best to keep both sets equal. One (the main showstopper?) for AT<1K is our own application, and we do have an inimplemented workaround. I think we'll have that done in like 4 months (because there is more pressing stuff around). > > > Configuring per client is not acceptable as the same client may operate in > > > different contexts and in some it is using some dumb services which have a > > > limit on access token size. > > Yes. Fully agree. > > > So what are the proposals here? Use some proprietary request parameter for > > > it? > > I really don't know. If this is really about which scopes go into which > > place (JWT vs userinfo), then something proprietary might not be so > > harmful. I'm sure this question will bother others, too. > > > > > > One way out, could be to live with the long ATs. > > > > I'll check with our OIDC expert, but this won't turn around before monday. > > > OK, let us know. > > If thinking about proprietary solution, I think we can have it. However I'd > keep it dead simple: just a flag "uy_put_claims_in_access_token", which > would put all claims in AT. He suggested using the same mechanism as in the "claims" place, but using a different keyword. He sends this reference: https://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter Maybe just calling it "claims_at" would be all it takes. -- Marcus. |
|
From: Krzysztof B. <kb...@un...> - 2022-02-28 11:11:45
|
Hi Marcus, W dniu 23.02.2022 o 18:06, Marcus Hardt pisze: > Hi Krzysztof, > > > On 23. Feb 2022 16:08, Krzysztof Benedyczak wrote: >> Hi, >> >> I'm leaving the longer thread below for reference, however the main open >> point is how to specify what should land in JWT-style access token. >> I see no security implications here, so that's not a problem. >> >> From what you wrote configuring that via scopes is not great as would make >> it hard for the clients. > I'm not sure I understand. Requesting specific scopes is in the standard. > I understand that the problem is which claims go into jwt AT and which > ones are in the userinfo-endpoint, right? Requesting scopes is in the standard, that's no problem. But as I understood Sander (and also can imagine on my own) that's bit of an organizational problem. Let's assume Unity allows admin to configure per scope, whether attributes of that scope should go to AT or not. Now, if you have clients that require no extra claims in AT and some with opposite requirement, then you will need to create a duplicate of each scope in Unity: profile; profile_in_at job_info; job_info_in_at ... which will differ only with that setting. Clunky, both from server side and client side. Also a small clarification: user-info endpoint will always return all claims. The only problem to decide is which claims also are put into JWT AT. > >> Configuring per client is not acceptable as the same client may operate in >> different contexts and in some it is using some dumb services which have a >> limit on access token size. > Yes. Fully agree. > >> So what are the proposals here? Use some proprietary request parameter for >> it? > I really don't know. If this is really about which scopes go into which > place (JWT vs userinfo), then something proprietary might not be so > harmful. I'm sure this question will bother others, too. > > > One way out, could be to live with the long ATs. > > I'll check with our OIDC expert, but this won't turn around before monday. OK, let us know. If thinking about proprietary solution, I think we can have it. However I'd keep it dead simple: just a flag "uy_put_claims_in_access_token", which would put all claims in AT. Thanks, Krzysztof |
|
From: Roman K. <ro...@un...> - 2022-02-28 06:15:17
|
Dear Subscribers, A new patch release was published with the following content: - Unity-IdM manual has now reference to upmon configuration, - two fixes for problems found with migrations, for one of which there might be a need to perform a manual procedure described below Note that we have found a problem with our latest migration. Is triggered by OAuth endpoint configuration which is not utilizing the "Refresh token expiration" feature. The problem is manifesting after Unity-IdM startup with the following error log entry: ERROR unity.server.core.InternalEndpointManagement: Can't load endpoint Jirav Admin OAuth2 Authorization Server of type OAuth2Authz eu.unicore.util.configuration.ConfigurationException: Can't initialize the OAuth 2 AS endpoint's configuration (...) Caused by: eu.unicore.util.configuration.ConfigurationException: Scope offline_access is required, refresh token issue policy is OFFLINE_SCOPE_BASED If you run into such a problem after 3.8.1 installation, it has to be fixed manually. Using console edit problematic endpoint(s), update the "Refresh token issue policy" to Never, and then deploy the endpoint. More details available at https://unity-idm.eu/releases/3-8-2-has-been-released/ Best regards, Roman |
|
From: Marcus H. <ha...@ki...> - 2022-02-23 17:06:24
|
Hi Krzysztof, On 23. Feb 2022 16:08, Krzysztof Benedyczak wrote: > Hi, > > I'm leaving the longer thread below for reference, however the main open > point is how to specify what should land in JWT-style access token. > I see no security implications here, so that's not a problem. > > From what you wrote configuring that via scopes is not great as would make > it hard for the clients. I'm not sure I understand. Requesting specific scopes is in the standard. I understand that the problem is which claims go into jwt AT and which ones are in the userinfo-endpoint, right? > Configuring per client is not acceptable as the same client may operate in > different contexts and in some it is using some dumb services which have a > limit on access token size. Yes. Fully agree. > So what are the proposals here? Use some proprietary request parameter for > it? I really don't know. If this is really about which scopes go into which place (JWT vs userinfo), then something proprietary might not be so harmful. I'm sure this question will bother others, too. One way out, could be to live with the long ATs. I'll check with our OIDC expert, but this won't turn around before monday. M. > Cheers, > Krzysztof > > > > > > > W dniu 22.02.2022 o 08:08, Sander Apweiler pisze: > > Good morning, > > > > On Mon, 2022-02-21 at 17:29 +0100, Marcus Hardt wrote: > > > On 21. Feb 2022 12:03, Krzysztof Benedyczak wrote: > > > > And here the remaining part of the original thread, related to > > > > extra claims > > > > in id/access tokens. > > > > > > > > W dniu 21.02.2022 o 11:42, Sander Apweiler pisze: > > > > > > > > The second request we got is about user attributes within > > > > > > > > the > > > > > > > > token. The user, who made the request told us that the > > > > > > > > targeted > > > > > > > > software does not support requests to userinfo endpoint and > > > > > > > > does > > > > > > > > not keep consistent information about the user. For this > > > > > > > > they > > > > > > > > need information about the user in the token itself. I got > > > > > > > > the > > > > > > > > friendly hint that WLCG does it in this way. We already > > > > > > > > talked > > > > > > > > in the past about the possibility to add own claims. Maybe > > > > > > > > the > > > > > > > > better solution would be supporting the request parameter > > > > > > > > to > > > > > > > > allow SPs to request the needed claims itself instead of > > > > > > > > adding > > > > > > > > some claims in general. Would this be an option for unity? > > > > > > > We have a ticket on that already recorded, and is on the top > > > > > > > of > > > > > > > open source queue. > > > > > > > > > > > > > > Although we understand this bit differently. We were thinking > > > > > > > about server-side controlled setting to include some of the > > > > > > > claims > > > > > > > (attributes) in the id token (applies to oidc mode only). > > > > > > > Perhaps > > > > > > > configured per scope (as we have attributes bound to scopes). > > > > > > > > > > > > > > Putting client in control of that sounds as a bit of an > > > > > > > overkill. > > > > > > > Especially if you want to allow client to pick and choose > > > > > > > which > > > > > > > individual attributesshould go into id token. Is there a > > > > > > > strong > > > > > > > use case for that? > > > > > > I guess this goes a bit like the scopes clients can request to > > > > > > be > > > > > > available in the userinfo endpoint. > > > > > > > > > > > > The current headache this brings up for the AccessTokens is > > > > > > that we > > > > > > have two compeing use cases. One would like to have all > > > > > > authorisation statements inside the token, so it never ever > > > > > > needs to > > > > > > contact the OP, while the other needs tokens below the 1k > > > > > > limit. > > > > > > > > > > > > Both of these use cases can be asked to work around this. I > > > > > > don't > > > > > > have a strong opinion here. > > > > > I guess the first ticket was also initiated by me. The first Idea > > > > > was > > > > > to have it under server control, because it was "only" > > > > > groupmembership > > > > > information which was needed by some services. In meantime other > > > > > services requests other attributes in the access token. > > > > > > > > > > Putting more information in the AT, the large size of it creates > > > > > problems for some other service. For this reason we do not want > > > > > to put > > > > > to many additional attributes in the AT. In the best case only > > > > > the > > > > > attributes which are needed by the specific service. For this the > > > > > services need a way to signal it to unity. Of course the unity > > > > > administrators must be able to limit/configure which attributes > > > > > could > > > > > be released within the AT. > > > > > > > > > > I don't know if the specification contains something about this. > > > > > If not > > > > > hinting the needed attributes in the token via specific scopes > > > > > might be > > > > > a way. > > > > Well, so it seems we have a small confusion. Id token, or JWT > > > > access token? > > > Here it's about attributes in the JWT acess token. > > Yes JWT access token. Sorry for the confusion. Writing email between > > several meetings is no good idea. :( > > > > For the other part of the question, i.e. how to request and or > > > > configure it > > > > seems that this is strongly client-specific. So why not tho have > > > > this switch > > > > per-client? Sounds as the easiest way forward. > > > Client specific could cause problems. Assume oidc-agent is the client > > > in > > > two cases, once for ssh (AT < 1k required for the time being) and > > > once for > > > data access (server wanting to check authorisation offline). > > > > > > I'd rather let the client request the scopes that it needs. Then the > > > corresponding claims will be sent, no? > > > > > > E.g. I'd pick a subset of the advertised scopes in > > > https://login.helmholtz.de/oauth2/.well-known/openid-configuration > > > > > I guess the problem is that at least some services reuse token, e.g. > > from oidc agent. So client specific won't work fully. At least for one > > service I know the users use the oidc agent to get the token for the > > service. Another service which requested this feature did have it's own > > client registered. > > > > Configuration with scopes would also work, but would require more > > > > dev work, > > > > and then more configuration (admin would need to double number of > > > > scopes, to > > > > have variants with a thin token, or fully packed. > > > Hmm. I'm not sure I understand this. > > > > > I'm not sure if the administrativ overhead is that much for service > > administrators. Because they configure once which scopes their service > > need. I think the overhead is on side of the not technical experts, > > using the oidc client, which need to adopt the requested scopes for > > each new access token, according to the service they want to use. > > > > Best regards, > > Sander > > -- Marcus. |
|
From: Krzysztof B. <kb...@un...> - 2022-02-23 15:08:40
|
Hi, I'm leaving the longer thread below for reference, however the main open point is how to specify what should land in JWT-style access token. I see no security implications here, so that's not a problem. From what you wrote configuring that via scopes is not great as would make it hard for the clients. Configuring per client is not acceptable as the same client may operate in different contexts and in some it is using some dumb services which have a limit on access token size. So what are the proposals here? Use some proprietary request parameter for it? Cheers, Krzysztof W dniu 22.02.2022 o 08:08, Sander Apweiler pisze: > Good morning, > > On Mon, 2022-02-21 at 17:29 +0100, Marcus Hardt wrote: >> On 21. Feb 2022 12:03, Krzysztof Benedyczak wrote: >>> And here the remaining part of the original thread, related to >>> extra claims >>> in id/access tokens. >>> >>> W dniu 21.02.2022 o 11:42, Sander Apweiler pisze: >>>>>>> The second request we got is about user attributes within >>>>>>> the >>>>>>> token. The user, who made the request told us that the >>>>>>> targeted >>>>>>> software does not support requests to userinfo endpoint and >>>>>>> does >>>>>>> not keep consistent information about the user. For this >>>>>>> they >>>>>>> need information about the user in the token itself. I got >>>>>>> the >>>>>>> friendly hint that WLCG does it in this way. We already >>>>>>> talked >>>>>>> in the past about the possibility to add own claims. Maybe >>>>>>> the >>>>>>> better solution would be supporting the request parameter >>>>>>> to >>>>>>> allow SPs to request the needed claims itself instead of >>>>>>> adding >>>>>>> some claims in general. Would this be an option for unity? >>>>>> We have a ticket on that already recorded, and is on the top >>>>>> of >>>>>> open source queue. >>>>>> >>>>>> Although we understand this bit differently. We were thinking >>>>>> about server-side controlled setting to include some of the >>>>>> claims >>>>>> (attributes) in the id token (applies to oidc mode only). >>>>>> Perhaps >>>>>> configured per scope (as we have attributes bound to scopes). >>>>>> >>>>>> Putting client in control of that sounds as a bit of an >>>>>> overkill. >>>>>> Especially if you want to allow client to pick and choose >>>>>> which >>>>>> individual attributesshould go into id token. Is there a >>>>>> strong >>>>>> use case for that? >>>>> I guess this goes a bit like the scopes clients can request to >>>>> be >>>>> available in the userinfo endpoint. >>>>> >>>>> The current headache this brings up for the AccessTokens is >>>>> that we >>>>> have two compeing use cases. One would like to have all >>>>> authorisation statements inside the token, so it never ever >>>>> needs to >>>>> contact the OP, while the other needs tokens below the 1k >>>>> limit. >>>>> >>>>> Both of these use cases can be asked to work around this. I >>>>> don't >>>>> have a strong opinion here. >>>> I guess the first ticket was also initiated by me. The first Idea >>>> was >>>> to have it under server control, because it was "only" >>>> groupmembership >>>> information which was needed by some services. In meantime other >>>> services requests other attributes in the access token. >>>> >>>> Putting more information in the AT, the large size of it creates >>>> problems for some other service. For this reason we do not want >>>> to put >>>> to many additional attributes in the AT. In the best case only >>>> the >>>> attributes which are needed by the specific service. For this the >>>> services need a way to signal it to unity. Of course the unity >>>> administrators must be able to limit/configure which attributes >>>> could >>>> be released within the AT. >>>> >>>> I don't know if the specification contains something about this. >>>> If not >>>> hinting the needed attributes in the token via specific scopes >>>> might be >>>> a way. >>> Well, so it seems we have a small confusion. Id token, or JWT >>> access token? >> Here it's about attributes in the JWT acess token. > Yes JWT access token. Sorry for the confusion. Writing email between > several meetings is no good idea. :( >>> For the other part of the question, i.e. how to request and or >>> configure it >>> seems that this is strongly client-specific. So why not tho have >>> this switch >>> per-client? Sounds as the easiest way forward. >> Client specific could cause problems. Assume oidc-agent is the client >> in >> two cases, once for ssh (AT < 1k required for the time being) and >> once for >> data access (server wanting to check authorisation offline). >> >> I'd rather let the client request the scopes that it needs. Then the >> corresponding claims will be sent, no? >> >> E.g. I'd pick a subset of the advertised scopes in >> https://login.helmholtz.de/oauth2/.well-known/openid-configuration >> > I guess the problem is that at least some services reuse token, e.g. > from oidc agent. So client specific won't work fully. At least for one > service I know the users use the oidc agent to get the token for the > service. Another service which requested this feature did have it's own > client registered. >>> Configuration with scopes would also work, but would require more >>> dev work, >>> and then more configuration (admin would need to double number of >>> scopes, to >>> have variants with a thin token, or fully packed. >> Hmm. I'm not sure I understand this. >> > I'm not sure if the administrativ overhead is that much for service > administrators. Because they configure once which scopes their service > need. I think the overhead is on side of the not technical experts, > using the oidc client, which need to adopt the requested scopes for > each new access token, according to the service they want to use. > > Best regards, > Sander |
|
From: Krzysztof B. <kb...@un...> - 2022-02-23 14:55:33
|
Hi, W dniu 22.02.2022 o 07:57, Sander Apweiler pisze: > Good morning, > > On Mon, 2022-02-21 at 17:21 +0100, Marcus Hardt wrote: >> On 21. Feb 2022 11:53, Krzysztof Benedyczak wrote: >>> Gents, >>> >>> As we have 2 topics here let me break the thread into two. >> Many thanks (I was shocked by seeing the length of the email). >> >>> Here audience goes >>> W dniu 21.02.2022 o 11:42, Sander Apweiler pisze: >>>> Good morning Krzysztof, >>>> I'm sorry for the delay. There were a lot of meetings end of last >>>> week >>>> and I had no time answer earlier. >>>> >>>> On Thu, 2022-02-17 at 10:16 +0100, Marcus Hardt wrote: >>>>> On 16. Feb 2022 23:03, Krzysztof Benedyczak wrote: >>>>>> Hi Sander, >>>>>> >>>>>> let me ask for few clarifications. >>>>>> >>>>>> W dniu 15.02.2022 o 15:26, Sander Apweiler pisze: >>>>>>> Hello Krzysztof, >>>>>>> hello Roman, >>>>>>> >>>>>>> since our connected SPs are growing we do get further >>>>>>> feature >>>>>>> request, >>>>>>> which I want to share with you. >>>>>>> >>>>>>> The first one is a possibility to change the aud of a >>>>>>> registered >>>>>>> client. At the moment unity uses the registered username of >>>>>>> the >>>>>>> OIDC >>>>>>> client, which is fine according to the RFC. But there are >>>>>>> connected >>>>>>> services which does the audience use, too. In this specific >>>>>>> use- >>>>>>> case >>>>>>> the token was generated by the user using the oidc-agent >>>>>>> tool >>>>>>> [1]. The >>>>>>> generated token was send via an API to dCache which >>>>>>> validates the >>>>>>> token. dCache is also checking the audience and rejects all >>>>>>> token >>>>>>> having an unsupported audience. The OIDC agent has an >>>>>>> option the >>>>>>> request a specific aud value for the token and forwards >>>>>>> this >>>>>>> request to >>>>>>> the AS. Together with the request users showed us examples >>>>>>> where >>>>>>> Indigo >>>>>>> IAM do support this. Would it possible to implement this >>>>>>> unity, >>>>>>> too? >>>>>> So for the support of multiple audiences per client - >>>>>> certainly >>>>>> that's >>>>>> possible. I understand that this is just a configuration of >>>>>> allowed >>>>>> additional audiences. Each of such audience should have its >>>>>> identifier and >>>>>> have to be returned. Easy. >>>>>> >>>>>> Can you tell more what is the purpose of "requesting" of a >>>>>> specific >>>>>> audience >>>>>> by the client? I think it is some proprietary feature of >>>>>> Indigo >>>>>> IAM. We can >>>>>> have it, but sounds like a bigger work, and I need to >>>>>> understand >>>>>> the purpose >>>>>> and details of the use case. Also, technically, would that be >>>>>> just >>>>>> narrowing >>>>>> of the allowed audiences of the client? Shall that be then >>>>>> also >>>>>> presented on >>>>>> consent screen? >>>>>> >>>>>> The aud claim is a bit weird. >>>>>> >>>>>> In the oidc core spec I find it mostly in the ID Token, where >>>>>> "it >>>>>> MUST >>>>>> contain the OAuth 2.0 client_id". >>>>>> >>>>>> It does make sense to be mandatory, and to be the client_id >>>>>> for the >>>>>> ID >>>>>> Token, because the ID Token is for that specific client_id >>>>>> only. >>>>>> >>>>>> >>>>>> The aud claim is also used in JWT ATs, and therein became >>>>>> mandatory >>>>>> via >>>>>> RFC9068[1] / RFC7519[2]. Just: The notion of the client_id >>>>>> isn't >>>>>> there, >>>>>> because ATs may also be intended for others than only a >>>>>> specific >>>>>> client_id. >>>>>> [1] >>>>>> https://www.rfc-editor.org/rfc/rfc9068#name-data-structure >>>>>> [2] https://www.rfc-editor.org/rfc/rfc7519#section-4.1.3 >>>>>> >>>>>> This lead the WLCG people to use it for their purposes [3] >>>>>> [3] https://zenodo.org/record/3460258 >>>>>> >>>>>> Funny enough, [3] states >>>>>> >>>>>> The contents of the claim may either be a string or URL; >>>>>> we do >>>>>> not >>>>>> currently provide specific guidance on selecting >>>>>> audience names. >>>>>> >>>>>> Also, they forget to mention that it's a JSON list, not a >>>>>> space >>>>>> separated >>>>>> list of strings. >>>>>> >>>>>> >>>>>> By now, people started using it for different ways to specify >>>>>> who >>>>>> should >>>>>> use the token. dCache is already tokens that it considers >>>>>> not >>>>>> intended >>>>>> for itself. >>>>>> >>>>>> With the WLCG profile of Indigo-IAM this works "well". >>>>>> >>>>>> >>>>>> With oidc-agent we simply allow users to specify what they >>>>>> want to >>>>>> have in >>>>>> the token. >>>>>> >>>>>> In the lack of an existing spec, oidc-agent first implemented >>>>>> something IAM >>>>>> specific, and will move to useing RFC8707[4] to request >>>>>> specific >>>>>> scopes. >>>>>> [4] https://www.rfc-editor.org/rfc/rfc8707 >>>>>> >>>>>> >>>> Beside the specification hints from Marcus and the background for >>>> implementing it in oidc-agent, I just can add that we had request >>>> from >>>> different service providers, I guess all of them knows Indigo >>>> IAM, if >>>> we could make the aud claim adjustable because they do want to >>>> limit >>>> token acceptance to tokens which contain their service in the aud >>>> claim. But all of this services are using command line and tokens >>>> which >>>> was collected e.g. using oidc-agent. >>> @Marcus all you wrote is consistent with my understanding, however >>> thanks >>> for the RFC8707 link - I was missing that. >>> >>> Having that the situation is much more clear: the request is to >>> implement >>> that RFC. >>> >>> My doubts are around two aspects here: >>> >>> 1. shall we have the allowed audiences preregistered per-client (or >>> authorization server endpoint) in Unity? This will allow for >>> control of >>> which audiences are in general allowed for client as well as to >>> present them >>> in readable form on consent screen. -> My current thinking here is: >>> no, that >>> can be done later if/when needed. >> Yes, I think I was this is what is also sometimes done for the >> allowed >> scopes per client. But a) I'm not sure if there is (already) a valid >> use >> case for this, and b) it causes more pain to the client registration >> process. >> Add-on-demand seems ideal. > I agree too. The most clients might not be need this and those services > where we get the requests do not have their own clients and want to > reuse tokens which was created by someone else. >> >>> 2. shall we present requested audiences on consent screen? -> My >>> thinking >>> here is: yes, we should. Actually currently audience is restricted >>> to the >>> client itself, which can use the token on other services only if >>> those >>> services ignore audience claim. So if Unity will "officially" allow >>> for >>> additional audiences, it shoud inform about that. >> Yes, that probably makes sense too (although, judging from myself, >> the >> consent screen hardly receives the attention that it should). >> > Yes make sens. Although most users use the remember function. OK, so I think everything is clear here. I'll open a ticket, we will prioritize it, I think that won't be big work, so should be sooner than later. Best, Krzysztof |
|
From: Sander A. <sa....@fz...> - 2022-02-22 07:08:33
|
Good morning, On Mon, 2022-02-21 at 17:29 +0100, Marcus Hardt wrote: > On 21. Feb 2022 12:03, Krzysztof Benedyczak wrote: > > And here the remaining part of the original thread, related to > > extra claims > > in id/access tokens. > > > > W dniu 21.02.2022 o 11:42, Sander Apweiler pisze: > > > > > > The second request we got is about user attributes within > > > > > > the > > > > > > token. The user, who made the request told us that the > > > > > > targeted > > > > > > software does not support requests to userinfo endpoint and > > > > > > does > > > > > > not keep consistent information about the user. For this > > > > > > they > > > > > > need information about the user in the token itself. I got > > > > > > the > > > > > > friendly hint that WLCG does it in this way. We already > > > > > > talked > > > > > > in the past about the possibility to add own claims. Maybe > > > > > > the > > > > > > better solution would be supporting the request parameter > > > > > > to > > > > > > allow SPs to request the needed claims itself instead of > > > > > > adding > > > > > > some claims in general. Would this be an option for unity? > > > > > We have a ticket on that already recorded, and is on the top > > > > > of > > > > > open source queue. > > > > > > > > > > Although we understand this bit differently. We were thinking > > > > > about server-side controlled setting to include some of the > > > > > claims > > > > > (attributes) in the id token (applies to oidc mode only). > > > > > Perhaps > > > > > configured per scope (as we have attributes bound to scopes). > > > > > > > > > > Putting client in control of that sounds as a bit of an > > > > > overkill. > > > > > Especially if you want to allow client to pick and choose > > > > > which > > > > > individual attributesshould go into id token. Is there a > > > > > strong > > > > > use case for that? > > > > I guess this goes a bit like the scopes clients can request to > > > > be > > > > available in the userinfo endpoint. > > > > > > > > The current headache this brings up for the AccessTokens is > > > > that we > > > > have two compeing use cases. One would like to have all > > > > authorisation statements inside the token, so it never ever > > > > needs to > > > > contact the OP, while the other needs tokens below the 1k > > > > limit. > > > > > > > > Both of these use cases can be asked to work around this. I > > > > don't > > > > have a strong opinion here. > > > > I guess the first ticket was also initiated by me. The first Idea > > > was > > > to have it under server control, because it was "only" > > > groupmembership > > > information which was needed by some services. In meantime other > > > services requests other attributes in the access token. > > > > > > Putting more information in the AT, the large size of it creates > > > problems for some other service. For this reason we do not want > > > to put > > > to many additional attributes in the AT. In the best case only > > > the > > > attributes which are needed by the specific service. For this the > > > services need a way to signal it to unity. Of course the unity > > > administrators must be able to limit/configure which attributes > > > could > > > be released within the AT. > > > > > > I don't know if the specification contains something about this. > > > If not > > > hinting the needed attributes in the token via specific scopes > > > might be > > > a way. > > > > Well, so it seems we have a small confusion. Id token, or JWT > > access token? > > Here it's about attributes in the JWT acess token. Yes JWT access token. Sorry for the confusion. Writing email between several meetings is no good idea. :( > > > For the other part of the question, i.e. how to request and or > > configure it > > seems that this is strongly client-specific. So why not tho have > > this switch > > per-client? Sounds as the easiest way forward. > > Client specific could cause problems. Assume oidc-agent is the client > in > two cases, once for ssh (AT < 1k required for the time being) and > once for > data access (server wanting to check authorisation offline). > > I'd rather let the client request the scopes that it needs. Then the > corresponding claims will be sent, no? > > E.g. I'd pick a subset of the advertised scopes in > https://login.helmholtz.de/oauth2/.well-known/openid-configuration > I guess the problem is that at least some services reuse token, e.g. from oidc agent. So client specific won't work fully. At least for one service I know the users use the oidc agent to get the token for the service. Another service which requested this feature did have it's own client registered. > > > Configuration with scopes would also work, but would require more > > dev work, > > and then more configuration (admin would need to double number of > > scopes, to > > have variants with a thin token, or fully packed. > > Hmm. I'm not sure I understand this. > I'm not sure if the administrativ overhead is that much for service administrators. Because they configure once which scopes their service need. I think the overhead is on side of the not technical experts, using the oidc client, which need to adopt the requested scopes for each new access token, according to the service they want to use. 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: Sander A. <sa....@fz...> - 2022-02-22 06:57:33
|
Good morning, On Mon, 2022-02-21 at 17:21 +0100, Marcus Hardt wrote: > On 21. Feb 2022 11:53, Krzysztof Benedyczak wrote: > > Gents, > > > > As we have 2 topics here let me break the thread into two. > > Many thanks (I was shocked by seeing the length of the email). > > > Here audience goes > > W dniu 21.02.2022 o 11:42, Sander Apweiler pisze: > > > Good morning Krzysztof, > > > I'm sorry for the delay. There were a lot of meetings end of last > > > week > > > and I had no time answer earlier. > > > > > > On Thu, 2022-02-17 at 10:16 +0100, Marcus Hardt wrote: > > > > On 16. Feb 2022 23:03, Krzysztof Benedyczak wrote: > > > > > Hi Sander, > > > > > > > > > > let me ask for few clarifications. > > > > > > > > > > W dniu 15.02.2022 o 15:26, Sander Apweiler pisze: > > > > > > Hello Krzysztof, > > > > > > hello Roman, > > > > > > > > > > > > since our connected SPs are growing we do get further > > > > > > feature > > > > > > request, > > > > > > which I want to share with you. > > > > > > > > > > > > The first one is a possibility to change the aud of a > > > > > > registered > > > > > > client. At the moment unity uses the registered username of > > > > > > the > > > > > > OIDC > > > > > > client, which is fine according to the RFC. But there are > > > > > > connected > > > > > > services which does the audience use, too. In this specific > > > > > > use- > > > > > > case > > > > > > the token was generated by the user using the oidc-agent > > > > > > tool > > > > > > [1]. The > > > > > > generated token was send via an API to dCache which > > > > > > validates the > > > > > > token. dCache is also checking the audience and rejects all > > > > > > token > > > > > > having an unsupported audience. The OIDC agent has an > > > > > > option the > > > > > > request a specific aud value for the token and forwards > > > > > > this > > > > > > request to > > > > > > the AS. Together with the request users showed us examples > > > > > > where > > > > > > Indigo > > > > > > IAM do support this. Would it possible to implement this > > > > > > unity, > > > > > > too? > > > > > So for the support of multiple audiences per client - > > > > > certainly > > > > > that's > > > > > possible. I understand that this is just a configuration of > > > > > allowed > > > > > additional audiences. Each of such audience should have its > > > > > identifier and > > > > > have to be returned. Easy. > > > > > > > > > > Can you tell more what is the purpose of "requesting" of a > > > > > specific > > > > > audience > > > > > by the client? I think it is some proprietary feature of > > > > > Indigo > > > > > IAM. We can > > > > > have it, but sounds like a bigger work, and I need to > > > > > understand > > > > > the purpose > > > > > and details of the use case. Also, technically, would that be > > > > > just > > > > > narrowing > > > > > of the allowed audiences of the client? Shall that be then > > > > > also > > > > > presented on > > > > > consent screen? > > > > > > > > > > The aud claim is a bit weird. > > > > > > > > > > In the oidc core spec I find it mostly in the ID Token, where > > > > > "it > > > > > MUST > > > > > contain the OAuth 2.0 client_id". > > > > > > > > > > It does make sense to be mandatory, and to be the client_id > > > > > for the > > > > > ID > > > > > Token, because the ID Token is for that specific client_id > > > > > only. > > > > > > > > > > > > > > > The aud claim is also used in JWT ATs, and therein became > > > > > mandatory > > > > > via > > > > > RFC9068[1] / RFC7519[2]. Just: The notion of the client_id > > > > > isn't > > > > > there, > > > > > because ATs may also be intended for others than only a > > > > > specific > > > > > client_id. > > > > > [1] > > > > > https://www.rfc-editor.org/rfc/rfc9068#name-data-structure > > > > > [2] https://www.rfc-editor.org/rfc/rfc7519#section-4.1.3 > > > > > > > > > > This lead the WLCG people to use it for their purposes [3] > > > > > [3] https://zenodo.org/record/3460258 > > > > > > > > > > Funny enough, [3] states > > > > > > > > > > The contents of the claim may either be a string or URL; > > > > > we do > > > > > not > > > > > currently provide specific guidance on selecting > > > > > audience names. > > > > > > > > > > Also, they forget to mention that it's a JSON list, not a > > > > > space > > > > > separated > > > > > list of strings. > > > > > > > > > > > > > > > By now, people started using it for different ways to specify > > > > > who > > > > > should > > > > > use the token. dCache is already tokens that it considers > > > > > not > > > > > intended > > > > > for itself. > > > > > > > > > > With the WLCG profile of Indigo-IAM this works "well". > > > > > > > > > > > > > > > With oidc-agent we simply allow users to specify what they > > > > > want to > > > > > have in > > > > > the token. > > > > > > > > > > In the lack of an existing spec, oidc-agent first implemented > > > > > something IAM > > > > > specific, and will move to useing RFC8707[4] to request > > > > > specific > > > > > scopes. > > > > > [4] https://www.rfc-editor.org/rfc/rfc8707 > > > > > > > > > > > > > Beside the specification hints from Marcus and the background for > > > implementing it in oidc-agent, I just can add that we had request > > > from > > > different service providers, I guess all of them knows Indigo > > > IAM, if > > > we could make the aud claim adjustable because they do want to > > > limit > > > token acceptance to tokens which contain their service in the aud > > > claim. But all of this services are using command line and tokens > > > which > > > was collected e.g. using oidc-agent. > > > > @Marcus all you wrote is consistent with my understanding, however > > thanks > > for the RFC8707 link - I was missing that. > > > > Having that the situation is much more clear: the request is to > > implement > > that RFC. > > > > My doubts are around two aspects here: > > > > 1. shall we have the allowed audiences preregistered per-client (or > > authorization server endpoint) in Unity? This will allow for > > control of > > which audiences are in general allowed for client as well as to > > present them > > in readable form on consent screen. -> My current thinking here is: > > no, that > > can be done later if/when needed. > > Yes, I think I was this is what is also sometimes done for the > allowed > scopes per client. But a) I'm not sure if there is (already) a valid > use > case for this, and b) it causes more pain to the client registration > process. > Add-on-demand seems ideal. I agree too. The most clients might not be need this and those services where we get the requests do not have their own clients and want to reuse tokens which was created by someone else. > > > 2. shall we present requested audiences on consent screen? -> My > > thinking > > here is: yes, we should. Actually currently audience is restricted > > to the > > client itself, which can use the token on other services only if > > those > > services ignore audience claim. So if Unity will "officially" allow > > for > > additional audiences, it shoud inform about that. > > Yes, that probably makes sense too (although, judging from myself, > the > consent screen hardly receives the attention that it should). > Yes make sens. Although most users use the remember function. 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. Astrid Lambrecht, Prof. Dr. Frauke Melchior ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Roman K. <ro...@un...> - 2022-02-21 17:08:48
|
Dear Subscribers, I’m pleased to announce that Unity-IdM has launched public commercial support under the Authvisor trademark owned by Bixbit. Our partners with support contracts can request developments which get delivered on an agreed timeline. Our offering is both flexible and affordable to meet expectations of startups, SMEs and larger enterprises. For more information please visit: https://www.authvisor.com Bests regards, Unity-IdM Team |
|
From: Marcus H. <ha...@ki...> - 2022-02-21 16:29:18
|
On 21. Feb 2022 12:03, Krzysztof Benedyczak wrote: > And here the remaining part of the original thread, related to extra claims > in id/access tokens. > > W dniu 21.02.2022 o 11:42, Sander Apweiler pisze: > > > > > The second request we got is about user attributes within the > > > > > token. The user, who made the request told us that the targeted > > > > > software does not support requests to userinfo endpoint and does > > > > > not keep consistent information about the user. For this they > > > > > need information about the user in the token itself. I got the > > > > > friendly hint that WLCG does it in this way. We already talked > > > > > in the past about the possibility to add own claims. Maybe the > > > > > better solution would be supporting the request parameter to > > > > > allow SPs to request the needed claims itself instead of adding > > > > > some claims in general. Would this be an option for unity? > > > > We have a ticket on that already recorded, and is on the top of > > > > open source queue. > > > > > > > > Although we understand this bit differently. We were thinking > > > > about server-side controlled setting to include some of the claims > > > > (attributes) in the id token (applies to oidc mode only). Perhaps > > > > configured per scope (as we have attributes bound to scopes). > > > > > > > > Putting client in control of that sounds as a bit of an overkill. > > > > Especially if you want to allow client to pick and choose which > > > > individual attributesshould go into id token. Is there a strong > > > > use case for that? > > > I guess this goes a bit like the scopes clients can request to be > > > available in the userinfo endpoint. > > > > > > The current headache this brings up for the AccessTokens is that we > > > have two compeing use cases. One would like to have all > > > authorisation statements inside the token, so it never ever needs to > > > contact the OP, while the other needs tokens below the 1k limit. > > > > > > Both of these use cases can be asked to work around this. I don't > > > have a strong opinion here. > > I guess the first ticket was also initiated by me. The first Idea was > > to have it under server control, because it was "only" groupmembership > > information which was needed by some services. In meantime other > > services requests other attributes in the access token. > > > > Putting more information in the AT, the large size of it creates > > problems for some other service. For this reason we do not want to put > > to many additional attributes in the AT. In the best case only the > > attributes which are needed by the specific service. For this the > > services need a way to signal it to unity. Of course the unity > > administrators must be able to limit/configure which attributes could > > be released within the AT. > > > > I don't know if the specification contains something about this. If not > > hinting the needed attributes in the token via specific scopes might be > > a way. > > Well, so it seems we have a small confusion. Id token, or JWT access token? Here it's about attributes in the JWT acess token. > For the other part of the question, i.e. how to request and or configure it > seems that this is strongly client-specific. So why not tho have this switch > per-client? Sounds as the easiest way forward. Client specific could cause problems. Assume oidc-agent is the client in two cases, once for ssh (AT < 1k required for the time being) and once for data access (server wanting to check authorisation offline). I'd rather let the client request the scopes that it needs. Then the corresponding claims will be sent, no? E.g. I'd pick a subset of the advertised scopes in https://login.helmholtz.de/oauth2/.well-known/openid-configuration > Configuration with scopes would also work, but would require more dev work, > and then more configuration (admin would need to double number of scopes, to > have variants with a thin token, or fully packed. Hmm. I'm not sure I understand this. -- Marcus. |
