> I get that in practice it is likely that the CAS actually did just
> challenge for credentials on the TGT issuance, so perhaps this is OK
> from a security standpoint.
Likely, but not assured. The user might have logged in to CAS as long
ago as the TGT timeout (by default, two hours) before subsequently
logging in to the service configured to opt out of single sign on,
without being again challenged to present credentials.
Ability to log in to the service unchallenged two hours after having
last presented username and password feels to me to be outside the
spirit of what intent [renew=true | a service opting out of SSO]
communicates. When I opt my service out of participating in single
sign-on, I want users to have to present credentials in their attempt to
access my service. If CAS doesn't guarantee this behavior, then
plausibly I'll decide I can't rely upon CAS to provide the
authentication experience for my service.
> Thoughts?
My thought is that this is a defect, that unless credentials are
presented in the same user experience as the granting of the ST, CAS
should be prompting for re-presentation of primary credentials on user
attempt to login to an opted-out-of-SSO service.
I expect opting out of SSO in the services registry to be the same as
setting renew=true on the login and ticket validation requests. As
things stand, they're not: setting renew=true will always cause CAS to
show the login screen
<decision-state id="renewRequestCheck">
<if test="externalContext.requestParameterMap['renew'] neq
''&& externalContext.requestParameterMap['renew'] neq null"
then="viewLoginForm" else="generateServiceTicket" />
</decision-state>
Whereas opting out of SSO in the services registry has this edge case of
not showing the login form if the the TGT hasn't previously been used to
obtain any STs.
I expect it would be clearer to drive this registered service
configuration honoring navigation and behavior from the web flow, that
is, make this flow state
<decision-state id="renewRequestCheck">
<if test="externalContext.requestParameterMap['renew'] neq
''&& externalContext.requestParameterMap['renew'] neq null"
then="viewLoginForm" else="generateServiceTicket" />
</decision-state>
explicitly, procedurally handle testing the registration for the service
in question, rather than driving navigation to the login screen for
services opted out from SSO off an exception. Don't send the user to ST
issuance and rely upon it to fail when ST issuance is inappropriate
without the login screen -- gate this navigation up front and send the
user to the login experience, requiring that login experience to be
surpassed if the service has opted out of SSO.
Another thought is that ability to login to CAS without logging in to a
particular service is a misfeature at this point in CAS's evolution. In
practice, too few users and institutions are prepared to understand,
brand, and support what is at best a fringe use case of logging in to
CAS for the sake of establishing an SSO session without logging in to
any CAS-reliant service. I don't want to log in to CAS. I want to log
in to the portal, or LMS, or something, and maybe that incidentally
creates an SSO session. As such, I suggest that CAS evolve to not
bother to prompt for credentials and instead present a polite but
useless message when users visit CAS directly without specifying a
service - retire the
issuing-TGT-for-the-sake-of-establishing-SSO-session-only feature.
Andrew
On 08/02/2011 11:08 AM, William G. Thompson, Jr. wrote:
> Possibly another edge case...not sure.
>
> * Configure casapp service to opt-out of SSO via SM
> * Login directly to cas without a service parameter (i.e. /cas/login)
> and get a TGT
> * Login to casspp without credential challenge. (expected to be challenged)
>
> The result is an ability to by-pass the CAS Administrators indication
> that the app in question opt-out of SSO and always challenge for
> credentials.
>
> from CentralAuthenticationServiceImpl.grantServiceTicket():
> if (!registeredService.isSsoEnabled()&& credentials == null
> && ticketGrantingTicket.getCountOfUses()> 0) {
> log.warn("ServiceManagement: Service Not Allowed to use
> SSO. Service [" + service.getId() + "]");
> throw new UnauthorizedSsoServiceException();
>
> Since the TGT was issued by CAS without a ServiceTicket,
> getCountOfUsers == 0, so no credential challenge is issued, despite
> the config to do otherwise.
>
> I get that in practice it is likely that the CAS actually did just
> challenge for credentials on the TGT issuance, so perhaps this is OK
> from a security standpoint. Still it confused the deployer/cas admin
> for a bit.
>
> Thoughts?
>
> Bill
>
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-dev
