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
|
Nov
|
Dec
|
|
From: Krzysztof B. <kb...@un...> - 2022-03-21 12:45:31
|
Hi Sander, W dniu 18.03.2022 o 13:43, Sander Apweiler pisze: > Hi Krzysztof, > sorry for raising the next topic. Is it possible to sign the emails > sent by unity? I didn't find something in the manual or config about > it. Nope, sorry, there is no support for digital signing of emails outgoing from Unity (and we had no plans/requests to support that). Cheers, Krzysztof |
|
From: Sander A. <sa....@fz...> - 2022-03-18 12:43:24
|
Hi Krzysztof, sorry for raising the next topic. Is it possible to sign the emails sent by unity? I didn't find something in the manual or config about it. Have a nice weekend, Sander -- Federated Systems and Data Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Volker Rieke Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Astrid Lambrecht, Prof. Dr. Frauke Melchior ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Krzysztof B. <kb...@un...> - 2022-03-08 14:59:52
|
Hi, W dniu 08.03.2022 o 15:48, Marcus Hardt pisze: > Hi There, > > one note on this: > > if there is only a `scopes`, and no `scopes_at` in the request, one could > default to putting the same scopes into the AT and in the userinfo. I > think then it's least painful to introduce this. Well, only governed by endpoint config option "by default put all claims in JWT AT". We won't turn that on for everybody after an update, as we may run into problems in setups which relay on small AT (as your ;). KB |
|
From: Marcus H. <ha...@ki...> - 2022-03-08 14:48:24
|
Hi There, one note on this: if there is only a `scopes`, and no `scopes_at` in the request, one could default to putting the same scopes into the AT and in the userinfo. I think then it's least painful to introduce this. M. On 08. Mar 2022 07:20, Sander Apweiler wrote: > Good morning Krzysztof, > sorry for the delay. I had this still on my agenda. I think this would > work, too. > > I fully understand that the request of individuell claims is a lot of > work with very few usage. > > Cheers, > Sander > > On Mon, 2022-03-07 at 15:31 +0100, Krzysztof Benedyczak wrote: > > hi, > > > > W dniu 01.03.2022 o 17:06, Krzysztof Benedyczak pisze: > > > 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. > > > > Sander, any opinions here? > > > > Wrt to Marcus proposal, the name of the parameter can be "scopes_at" > > (or > > alike). > > > > That said I'm very doubtful whether this should go inside the > > 'claims' > > request parameter. Which as spec says is to request individual claims > > and would be counter intuitive to use it for specifying which scopes > > should go to AT (and we would need to support the base spec, which is > > kinda "ton of work and no one will use it"). > > > > 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 > ----------------------------------------------------------------------- > ----------------------------------------------------------------------- > > > > -- Marcus. |
|
From: Krzysztof B. <kb...@un...> - 2022-03-08 14:18:39
|
W dniu 08.03.2022 o 07:20, Sander Apweiler pisze: > Good morning Krzysztof, > sorry for the delay. I had this still on my agenda. I think this would > work, too. > > I fully understand that the request of individuell claims is a lot of > work with very few usage. OK, I've added that to backlog. Request to put all claims in JWT AT should be easy and we should have it relatively shortly, however we will see if we will also approach selection by scopes. Best, Krzysztof |
|
From: Krzysztof B. <kb...@un...> - 2022-03-08 14:13:27
|
Sander, W dniu 08.03.2022 o 07:24, Sander Apweiler pisze: > Good morning Krzysztof, > thanks for the swift reply. We updated it. Does it use a grid with > search option or do we have a very long list, because we are using > eduGAIN? It can use grid, and for a federation with many options there is no question that you should put it in the grid. Authentication configuration of this endpoint is all the same as all other endpoints. Best, Krzysztof |
|
From: Sander A. <sa....@fz...> - 2022-03-08 06:23:58
|
Good morning Krzysztof, thanks for the swift reply. We updated it. Does it use a grid with search option or do we have a very long list, because we are using eduGAIN? Cheers, Sander On Mon, 2022-03-07 at 15:26 +0100, Krzysztof Benedyczak wrote: > Hi Sander, > > W dniu 07.03.2022 o 07:40, Sander Apweiler pisze: > > 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? > > > This should be configured on a special Unity endpoint, which is > responsible for exposing mostly enquiry forms (what means that > requires > prior authentication). You can configure authentication of this > endpoint > in the way you want. The type of this endpoint is 'WellKnownLinks' > (should be ease to find it among your Services in Console). > > HTH, > Krzysztof > > -- Federated Systems and Data Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Volker Rieke Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Astrid Lambrecht, Prof. Dr. Frauke Melchior ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Sander A. <sa....@fz...> - 2022-03-08 06:20:07
|
Good morning Krzysztof, sorry for the delay. I had this still on my agenda. I think this would work, too. I fully understand that the request of individuell claims is a lot of work with very few usage. Cheers, Sander On Mon, 2022-03-07 at 15:31 +0100, Krzysztof Benedyczak wrote: > hi, > > W dniu 01.03.2022 o 17:06, Krzysztof Benedyczak pisze: > > 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. > > Sander, any opinions here? > > Wrt to Marcus proposal, the name of the parameter can be "scopes_at" > (or > alike). > > That said I'm very doubtful whether this should go inside the > 'claims' > request parameter. Which as spec says is to request individual claims > and would be counter intuitive to use it for specifying which scopes > should go to AT (and we would need to support the base spec, which is > kinda "ton of work and no one will use it"). > > 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-07 14:31:33
|
hi, W dniu 01.03.2022 o 17:06, Krzysztof Benedyczak pisze: > 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. Sander, any opinions here? Wrt to Marcus proposal, the name of the parameter can be "scopes_at" (or alike). That said I'm very doubtful whether this should go inside the 'claims' request parameter. Which as spec says is to request individual claims and would be counter intuitive to use it for specifying which scopes should go to AT (and we would need to support the base spec, which is kinda "ton of work and no one will use it"). Best, Krzysztof |
|
From: Krzysztof B. <kb...@un...> - 2022-03-07 14:26:45
|
Hi Sander, W dniu 07.03.2022 o 07:40, Sander Apweiler pisze: > 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? > This should be configured on a special Unity endpoint, which is responsible for exposing mostly enquiry forms (what means that requires prior authentication). You can configure authentication of this endpoint in the way you want. The type of this endpoint is 'WellKnownLinks' (should be ease to find it among your Services in Console). HTH, Krzysztof |
|
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 ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ |
