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:tjan...@gmail.com <javascript:>] > *Sent:* Wednesday, August 9, 2017 12:22 AM > *To:* CAS Community <cas-...@apereo.org <javascript:>> > *Cc:* mmoa...@unicon.net <javascript:> > *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 <https://tools.ietf.org/html/rfc6749#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 <http://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: > > 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:* cas-...@apereo.org [mailto:cas-...@apereo.org] *On Behalf Of *Tom > Andersson > *Sent:* Tuesday, August 8, 2017 12:32 AM > *To:* CAS Community <cas-...@apereo.org> > *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 cas-user+u...@apereo.org. > 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 > > <https://groups.google.com/a/apereo.org/d/msgid/cas-user/59d21bfd-052c-4311-acb6-ee47102ceaa1%40apereo.org?utm_medium=email&utm_source=footer> > . > > > > > ------------------------------ > > This email has been scanned for spam and viruses by Proofpoint Essentials. > Click here > <https://us2.proofpointessentials.com/index01.php?mod_id=11&mod_option=logitem&mail_id=1502263293-9sM7Jv0dy1uH&r_address=mmoayyed%40unicon.net&report=1> > > to report this email as spam. > > > = > -- - 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 cas-user+unsubscr...@apereo.org. 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.
