You are browsing a read-only backup copy of Wikitech. The live site can be found at wikitech.wikimedia.org

Difference between revisions of "CAS-SSO/Administration"

From Wikitech-static
Jump to navigation Jump to search
imported>Muehlenhoff
(API endpoints)
imported>Muehlenhoff
(Document CAS session handling properties)
Line 28: Line 28:
   
   
   curl https://idp.wikimedia.org/api/ssoSessions?type=ALL
   curl https://idp.wikimedia.org/api/ssoSessions?type=ALL
== Session timeout handling ==
First some terminology:
* A ''ticket-granting ticket'' (TGT) is an string generated by the CAS server that is issued after a successful authentication at the /login endpoint. When the TGT expires, no further SSO is possible. Conceptually, the life time of the TGT defines the lifetime of the SSO session.
* A ''ticket-granting cookie'' (TGC) is a cookie in your browser which identifies itself against CAS.
* A ''long term ticket granting ticket'' (LTGT) is used for automatic relogins when using the "remember me" feature, see below.
There are two ways for the user to authenticate when logging in:
* If "Remember me" is enabled, a long term authentication session is requested. This creates a "Long-Term Ticket Granting Ticket". As long as this LTGT is valid and the user has a valid TGC cookie, the session is automatically re-logged-in, which generates a new TGT. Security-wise this is acceptable if there are no other users for a computer, but must not be used when e.g. logging in from a shared computer.
* If "Remember me" is not enabled, the session life time is defined by the configuration parameters below and might need a relogin
The configuration properly '''cas.ticket.tgt.rememberMe.enabled''' enables/disables this feature.
For force a logout, either the ''logout/'' endpoint can be accessed (which voids the TGT (and the LTGT)) or the TCG cookie can be removed. When the TGC cookie is gone, the TGT of the user cannot be accessed, so no SSO is possible. If one wants to force that the TGC is rendered invalid when the browser session ends, this can be configured by setting '''tgc.maxAge'''=-1 (TODO: what is the default)
TGTs follow an LRU policy for expiration (similar to an Apache session timing out). The configuration property '''cas.ticket.tgt.timeToKillInSeconds''' configures a time interval in seconds (all time intervals mentioned here are specified in seconds); If a TGT isn't used until the time frame has passed, the TGT expires. For some reason there's also second setting with identical meaning '''tgt.timeout.maxTimeToLiveInSeconds''' which seems to be doing the same. (TODO: clarify with upstream if there's any difference)
The configuration property '''cas.ticket.tgt.maxTimeToLiveInSeconds''' defines an upper bound after which the TGT expires. A TGT is marked as expired once it's creation time plus the defined interval is reached (TicketGrantingTicketExpirationPolicy.isExpired())

Revision as of 14:11, 30 April 2020

Stub page with information on how to debug/handle Apereo CAS as deployed by the Wikimedia Foundation.

Icinga

$vhost requires authentication

This icinga check is in place to ensure protected sites correctly redirect and unauthenticated connection back to https://idp.wikimedia.org. You can run the check manually from icinga with the following command. (use the -v switch to increase verbosity)

icinga1001 ~ $ # test cas-icinga.wikimedia.org
icinga1001 ~ $ IP=208.80.154.84
icinga1001 ~ $ VHOST=cas-icinga.wikimedia.org
icinga1001 ~ $ URI=/icinga
208 ~ % /usr/lib/nagios/plugins/check_http -I ${IP} -H ${VHOST} -e 'HTTP/1.1 302' -d 'ocation: https://idp.wikimedia.org/login' -S -u ${URI}  
HTTP OK: Status line output matched "HTTP/1.1 302" - 604 bytes in 0.005 second response time |time=0.004526s;;;0.000000;10.000000 size=604B;;;0

common things to check

  • the -u switch points to the correct protected uri
  • The check is hitting the correct vhost
  • mod_auth_cas is correctly installed and configured

To debug mode_auth_cas update the vhost to have Loglevel debug & CASDebug On

API endpoints

The ssoSessions endpoint exports a JSON description of current sessions, restricted to access from the IDP hosts (currently disabled):

 curl https://idp.wikimedia.org/api/ssoSessions?type=ALL

Session timeout handling

First some terminology:

  • A ticket-granting ticket (TGT) is an string generated by the CAS server that is issued after a successful authentication at the /login endpoint. When the TGT expires, no further SSO is possible. Conceptually, the life time of the TGT defines the lifetime of the SSO session.
  • A ticket-granting cookie (TGC) is a cookie in your browser which identifies itself against CAS.
  • A long term ticket granting ticket (LTGT) is used for automatic relogins when using the "remember me" feature, see below.

There are two ways for the user to authenticate when logging in:

  • If "Remember me" is enabled, a long term authentication session is requested. This creates a "Long-Term Ticket Granting Ticket". As long as this LTGT is valid and the user has a valid TGC cookie, the session is automatically re-logged-in, which generates a new TGT. Security-wise this is acceptable if there are no other users for a computer, but must not be used when e.g. logging in from a shared computer.
  • If "Remember me" is not enabled, the session life time is defined by the configuration parameters below and might need a relogin

The configuration properly cas.ticket.tgt.rememberMe.enabled enables/disables this feature.

For force a logout, either the logout/ endpoint can be accessed (which voids the TGT (and the LTGT)) or the TCG cookie can be removed. When the TGC cookie is gone, the TGT of the user cannot be accessed, so no SSO is possible. If one wants to force that the TGC is rendered invalid when the browser session ends, this can be configured by setting tgc.maxAge=-1 (TODO: what is the default)

TGTs follow an LRU policy for expiration (similar to an Apache session timing out). The configuration property cas.ticket.tgt.timeToKillInSeconds configures a time interval in seconds (all time intervals mentioned here are specified in seconds); If a TGT isn't used until the time frame has passed, the TGT expires. For some reason there's also second setting with identical meaning tgt.timeout.maxTimeToLiveInSeconds which seems to be doing the same. (TODO: clarify with upstream if there's any difference)

The configuration property cas.ticket.tgt.maxTimeToLiveInSeconds defines an upper bound after which the TGT expires. A TGT is marked as expired once it's creation time plus the defined interval is reached (TicketGrantingTicketExpirationPolicy.isExpired())