At this point, no there isn't but speaking for myself, it is something that will likely get done prior to 5.3. It's not exactly high on my list.
It's not that difficult to do, and an OAuth service definition already has the placeholder to carry grant types it supports. The remaining work is to ensure whatever the service carries is in fact enforced. Your best bet at this point is put together a patch that executes that enforcement. --Misagh From: "Tom Andersson" <[email protected]> To: "CAS Community" <[email protected]> Cc: "Misagh Moayyed" <[email protected]> Sent: Tuesday, August 15, 2017 6:38:50 AM Subject: Re: [cas-user] CAS 5.0 & Resource Owner Grant Hi, Thanks for the tips! I saw you already implementing something for this on the master branch :) Related to this - is there currently no way to control which oAuth grant types are allowed per service? Running CAS 5.0.3 that is. That is, we'd like to enable Resource Owner Password grant for a single service, but not all of them (to me it seems like by default it's enabled on all oauth services). Cheers! Tom On Wednesday, 9 August 2017 12:39:02 UTC+3, Misagh Moayyed wrote: Cool. I feel uneasy about the spec saying “For example” :) but that’s neither here nor there. The mechanics of how one should proceed to patch this are fairly simple: find the spot that handles the GET request in the OAuth module, tune it to also accept POST and use that method/handler when dealing with the particular grant type. (This I think is the easiest approach; the possibly-better alternative to ensure that grant type can only respond to POST requires other [breaking] changes that would be outside the scope of 5.1) Start with OAuth20AuthorizeEndpointController and work your way up. Post a pull request when ready, or better yet, when not ready as a WIP so others see what you’re working on and can provide early feedback. More here: https://apereo.github.io/2017/07/05/cas-contribution-guide/ --Misagh From: Tom Andersson [mailto: [email protected] ] Sent: Wednesday, August 9, 2017 12:22 AM To: CAS Community < [email protected] > Cc: [email protected] Subject: Re: [cas-user] CAS 5.0 & Resource Owner Grant Hi Misagh! Not sure about hard rule, but: "The client makes a request to the token endpoint by adding the following parameters using the 'application/x-www-form-urlencoded' format per Appendix B with a character encoding of UTF-8 in the HTTP request entity-body" and "For example, the client makes the following HTTP request using transport-layer security (with extra line breaks for display purposes only):" POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=password&username=johndoe&password=A3ddj3w Referencing https://tools.ietf.org/html/rfc6749#section-4.3.2 . Do you think it would be relatively simple to patch this feature, or how should one proceed with such a change request? Cheers, Tom On Wednesday, 9 August 2017 09:33:27 UTC+3, Misagh Moayyed wrote: BQ_BEGIN I don’t remember if the spec makes a hard and fast rule on this, strictly speaking, but you’re certainly right that if it’s done via a GET it would be better for it to switch to POST. --Misagh From: [email protected] [mailto: [email protected] ] On Behalf Of Tom Andersson Sent: Tuesday, August 8, 2017 12:32 AM To: CAS Community < [email protected] > Subject: [cas-user] CAS 5.0 & Resource Owner Grant Hello, I have the need to provide an authentication mechanism using the oAuth2 Resource Owner Grant type. However if I've understood correctly, the implementation expects the user to authenticatite using GET and passing the credentials in the query parameters? To me this seems quite insecure as the credentials will then stick in access logs etc. I'm wondering why it's been implemented in this way instead of POSTing the credentials or if I have misunderstood something. Or would it be better to rely on the tickets REST api? Thank you! Tom -- - CAS gitter chatroom: https://gitter.im/apereo/cas - CAS mailing list guidelines: https://apereo.github.io/cas/Mailing-Lists.html - CAS documentation website: https://apereo.github.io/cas - CAS project website: https://github.com/apereo/cas --- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] . To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/59d21bfd-052c-4311-acb6-ee47102ceaa1%40apereo.org . This email has been scanned for spam and viruses by Proofpoint Essentials. Click here to report this email as spam. = BQ_END -- - CAS gitter chatroom: https://gitter.im/apereo/cas - CAS mailing list guidelines: https://apereo.github.io/cas/Mailing-Lists.html - CAS documentation website: https://apereo.github.io/cas - CAS project website: https://github.com/apereo/cas --- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] . To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/ed873605-cd91-48c2-b9a1-7c5942b94449%40apereo.org . -- - CAS gitter chatroom: https://gitter.im/apereo/cas - CAS mailing list guidelines: https://apereo.github.io/cas/Mailing-Lists.html - CAS documentation website: https://apereo.github.io/cas - CAS project website: https://github.com/apereo/cas --- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/1765403816.3702345.1502806282719.JavaMail.zimbra%40unicon.net.
