CAS 5.0 & Resource Owner Grant

59 views
Skip to first unread message

Tom Andersson

unread,
Aug 8, 2017, 3:31:46 AM8/8/17
to CAS Community
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

Misagh Moayyed

unread,
Aug 9, 2017, 2:33:27 AM8/9/17
to cas-...@apereo.org

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

--
- 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.

Tom Andersson

unread,
Aug 9, 2017, 3:21:31 AM8/9/17
to CAS Community, mmoa...@unicon.net
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



Do you think it would be relatively simple to patch this feature, or how should one proceed with such a change request?

Cheers,
Tom

Misagh Moayyed

unread,
Aug 9, 2017, 5:39:02 AM8/9/17
to CAS Community

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


This email has been scanned for spam and viruses by Proofpoint Essentials. Click here to report this email as spam.


=

Tom Andersson

unread,
Aug 15, 2017, 9:38:51 AM8/15/17
to CAS Community, mmoa...@unicon.net
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

Misagh Moayyed

unread,
Aug 15, 2017, 10:11:26 AM8/15/17
to cas-...@apereo.org
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" <tjan...@gmail.com>
To: "CAS Community" <cas-...@apereo.org>
Cc: "Misagh Moayyed" <mmoa...@unicon.net>
Sent: Tuesday, August 15, 2017 6:38:50 AM
Reply all
Reply to author
Forward
0 new messages