[
https://issues.apache.org/jira/browse/GUACAMOLE-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Harris updated GUACAMOLE-457:
----------------------------------
Description:
Per the CAS 2.0 protocol specification
(https://apereo.github.io/cas/5.1.x/protocol/CAS-Protocol-V2-Specification.html)
the URI for obtaining a ticket for an unauthenticated user is derived from the
base URI by appending `/login`. In the current source for CAS authentication
provider, the URI that is used for this purpose is the base URI (i.e. whatever
URL is configured as the value for the `cas-authorization-endpoint` property).
This prevents successful authentication using the provider with a
protocol-compliant CAS server.
Attempting to use the login URL as the value of the
`cas-authorization-endpoint` property as a workaround subsequently fails when
the validation URI is appended to the URL; this results in a URL that ends with
the path `/login/proxyValidate` which is incorrect and violates the CAS
protocol.
It seems that the solution could be as simple as appending `/login` to the
authorization endpoint URI in the AuthorizationServiceProvider, when the
CASTicketField object is constructed. Indeed a simple patch using this approach
was tested and confirmed to work properly with a protocol-compliant CAS server
implementation.
However, this approach allows some protocol specifics to leak into the
AuthorizationServiceProvider which otherwise relies on abstractions that wrap
classes of the Apereo CAS client. It does not appear that there is an
appropriate class/method provided by the CAS client library to construct the
login URL from the base URL. Perhaps simply adding a method to the extension's
TicketValidationService for this purpose would be reasonable.
was:
Per the CAS 2.0 protocol specification
(https://apereo.github.io/cas/5.1.x/protocol/CAS-Protocol-V2-Specification.html)
the URI for obtaining a ticket for an unauthenticated user is derived from the
base URI by appending `/login`. In the current source for CAS authentication
provider, the URI that is used for this purpose is the base URI (i.e. whatever
URL is configured as the value for the `cas-authorization-endpoint` property).
This prevents successful authentication using the provider with a
protocol-compliant CAS server.
Attempting to use the login URL as the value of the
`cas-authorization-endpoint` property as a workaround subsequently fails when
the validation URI is appended to the URL; this results in a URL that ends with
the path `/login/proxyValidate` which is incorrect and violates the CAS
protocol.
It seems that the solution could be as simple as appending `/login` to the
authorization endpoint URI in the AuthorizationServiceProvider, when the
CASTicketField object is constructed. Indeed a simple patch using this approach
was tested and confirmed to work properly with a protocol-compliant CAS server
implementation.
However, this approach allows some protocol specifics to leak into the
AuthorizationServiceProvider which otherwise relies on abstractions that wrap
classes of the Apereo CAS client. It does not appear that there is an
appropriate class provided by the CAS client library to construct the login URL
from the base URL. Perhaps simply adding a method to the extension's
TicketValidationService for this purpose would be reasonable.
> CAS authentication provider omits login URI
> -------------------------------------------
>
> Key: GUACAMOLE-457
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-457
> Project: Guacamole
> Issue Type: Bug
> Affects Versions: 0.9.13-incubating
> Reporter: Carl Harris
>
> Per the CAS 2.0 protocol specification
> (https://apereo.github.io/cas/5.1.x/protocol/CAS-Protocol-V2-Specification.html)
> the URI for obtaining a ticket for an unauthenticated user is derived from
> the base URI by appending `/login`. In the current source for CAS
> authentication provider, the URI that is used for this purpose is the base
> URI (i.e. whatever URL is configured as the value for the
> `cas-authorization-endpoint` property). This prevents successful
> authentication using the provider with a protocol-compliant CAS server.
> Attempting to use the login URL as the value of the
> `cas-authorization-endpoint` property as a workaround subsequently fails when
> the validation URI is appended to the URL; this results in a URL that ends
> with the path `/login/proxyValidate` which is incorrect and violates the CAS
> protocol.
> It seems that the solution could be as simple as appending `/login` to the
> authorization endpoint URI in the AuthorizationServiceProvider, when the
> CASTicketField object is constructed. Indeed a simple patch using this
> approach was tested and confirmed to work properly with a protocol-compliant
> CAS server implementation.
> However, this approach allows some protocol specifics to leak into the
> AuthorizationServiceProvider which otherwise relies on abstractions that wrap
> classes of the Apereo CAS client. It does not appear that there is an
> appropriate class/method provided by the CAS client library to construct the
> login URL from the base URL. Perhaps simply adding a method to the
> extension's TicketValidationService for this purpose would be reasonable.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
