Menu
▾
▴
unity-idm-discuss
|
From: Sander A. <sa....@fz...> - 2022-02-15 14:26:14
Attachments:
smime.p7s
|
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? 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? If you want we could discuss this request more detailed. Best regards, Sander [1]: https://indigo-dc.gitbook.io/oidc-agent/ -- 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-02-16 22:03:15
|
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 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? Best, Krzysztof |
|
From: Marcus H. <ha...@ki...> - 2022-02-17 09:32:18
Attachments:
smime.p7s
|
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 > > 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. -- Marcus. |
|
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: Marcus H. <ha...@ki...> - 2022-03-02 08:25:48
Attachments:
smime.p7s
|
[..] > > > > > 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: Sander A. <sa....@fz...> - 2022-02-21 10:42:40
Attachments:
smime.p7s
|
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. > > > > 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. Best regards, Sander > > _______________________________________________ > Unity-idm-discuss mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss -- Federated Systems and Data Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir 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-02-21 10:53:52
|
Gents, As we have 2 topics here let me break the thread into two. 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. 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. Does it make sense for you? Best, Krzysztof |
|
From: Krzysztof B. <kb...@un...> - 2022-02-21 11:04:02
|
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? 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. 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. WDYT? Krzysztof |
|
From: Marcus H. <ha...@ki...> - 2022-02-21 16:21:39
Attachments:
smime.p7s
|
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. > 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). -- Marcus. |
|
From: Marcus H. <ha...@ki...> - 2022-02-21 16:29:18
Attachments:
smime.p7s
|
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. |
|
From: Sander A. <sa....@fz...> - 2022-03-08 06:20:07
Attachments:
smime.p7s
|
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-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: Marcus H. <ha...@ki...> - 2022-03-08 14:48:24
Attachments:
smime.p7s
|
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: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: Sander A. <sa....@fz...> - 2022-02-22 06:57:33
Attachments:
smime.p7s
|
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: 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
Attachments:
smime.p7s
|
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: 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: Marcus H. <ha...@ki...> - 2022-02-23 17:06:24
Attachments:
smime.p7s
|
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-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: Marcus H. <ha...@ki...> - 2022-02-28 11:35:03
Attachments:
smime.p7s
|
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: Sander A. <sa....@fz...> - 2022-03-01 08:46:36
Attachments:
smime.p7s
|
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: 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-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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X