Re: [cas-user] CAS 5.0 & Resource Owner Grant

2017-08-15 Thread Misagh Moayyed
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" <tjande...@gmail.com> 
To: "CAS Community" <cas-user@apereo.org> 
Cc: "Misagh Moayyed" <mmoay...@unicon.net> 
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: tjan...@gmail.com ] 
Sent: Wednesday, August 9, 2017 12:22 AM 
To: CAS Community < cas-...@apereo.org > 
Cc: mmoa...@unicon.net 
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=johndoe=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: 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
 . 











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

Re: [cas-user] CAS 5.0 & Resource Owner Grant

2017-08-15 Thread Tom Andersson
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 ] 
> *Sent:* Wednesday, August 9, 2017 12:22 AM
> *To:* CAS Community <cas-...@apereo.org >
> *Cc:* mmoa...@unicon.net 
> *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=johndoe=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-ac

RE: [cas-user] CAS 5.0 & Resource Owner Grant

2017-08-09 Thread Misagh Moayyed
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:tjande...@gmail.com]
Sent: Wednesday, August 9, 2017 12:22 AM
To: CAS Community <cas-user@apereo.org>
Cc: mmoay...@unicon.net
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 
<https://tools.ietf.org/html/rfc6749#appendix-B> 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=johndoe=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_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_option=logitem_id=1502263293-9sM7Jv0dy1uH_address=mmoayyed%40unicon.net=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/0a2401d310f3%244597f400%24d0c7dc00%24%40unicon.net.


Re: [cas-user] CAS 5.0 & Resource Owner Grant

2017-08-09 Thread Tom Andersson
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=johndoe=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 
> *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
>  
> 
> .
>

-- 
- 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/f05b4530-8f78-4faa-92c5-a9d2f2ae178c%40apereo.org.


RE: [cas-user] CAS 5.0 & Resource Owner Grant

2017-08-09 Thread Misagh Moayyed
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-user@apereo.org [mailto:cas-user@apereo.org] On Behalf Of Tom 
Andersson
Sent: Tuesday, August 8, 2017 12:32 AM
To: CAS Community 
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+unsubscr...@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
 

 
.

-- 
- 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/086f01d310d9%245cd077b0%2416716710%24%40unicon.net.