Versions Compared

Old Version 4

changes.mady.by.user Former user (Deleted)

Saved on

compared with

New Version Current

changes.mady.by.user Former user (Deleted)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3
Panel
bgColor#FFFFCE
titleborderStyledashed
title

ENTR:Main Scenario ENTR:Extensions ENTR:Notes ENTR:References ENTR:Associated Modules ENTR:Implementations ENTR:Advice and ExperienceENTR:Contributors

Goal:

Anchor
goal
goal
Excerpt

Support CAS authentication to Sakai


Version:
Anchor
version
version
?
DG Priority:
Anchor
priority
priority
?
Status:
Anchor
support
support
partially implemented
Scope:
Anchor
scope
scope
?
Preconditions:
Anchor
pre
pre
A deployer has successfully deployed an instance of the Central Authentication Service.
Success end:
Anchor
success
success
The deployer configures the Sakai instance to offer "Log in via CAS" as the way users authenticate to Sakai.
Failed end:
Anchor
fail
fail
The deployer is unable to configure Sakai to authenticate users via the Central Authentication Service or has to ask questions on the Sakai or CAS email lists.
Actors:
Anchor
actors
actors
Sakai deployer, SEPP, JA-SIG CAS team.
Primary Actor:
Anchor
actor
actor
Sakai deployer
Trigger:
Anchor
trigger
trigger
A deployer wishes to use CAS for Single Sign On to Sakai.
Security Concerns:
Anchor
security
security
Sakai must properly validate the CAS service tickets. Sakai must properly reject proxy tickets from untrusted proxying entities (or reject all proxy tickets).
Logging:
Anchor
logging
logging
Sakai should log the login of users and record the way in which the user authenticated (awp9 logged in at TIMESTAMP via CAS). Sakai should log ticket validation failure, ideally logging the raw validation failure response / exceptional condition encountered. Sakai should intelligently log SSL / cert problems on ticket validation when encountered.
Performance Concerns:
Anchor
performance
performance
Sakai should not require a redirect to CAS on every request.

Anchor
main
main

Panel
bgColor#FFFFCE
borderStyledashed
titleMain Success Scenario
borderStyledashed

Deployer successfully configures Sakai instance such that: End user visits Sakai. Sakai offers a "Log in via CAS" button. User clicks button, authenticates to CAS, CAS redirects back to Sakai. Sakai validates service ticket, establishes user session, context, etc., user is authenticated to and logged into and begins using Sakai.

Anchor
ext
ext

Panel
borderStyle
bgColor#FFFFCE
borderStyledashed
titleExtensionsdashed

Anchor
refs
refs

Panel
borderStyle
bgColor#FFFFCE
borderStyledashed
titleReferencesdashed

See CAS website / JA-SIG

Anchor
modules
modules

Panel
bgColor#FFFFCE
borderStyledashed
titleAssociated ModulesborderStyledashed

Anchor
impl
impl

Panel
bgColor#FFFFCE
borderStyledashed
titleImplementationsborderStyledashed

Anchor
advice
advice

Panel
bgColor#FFFFCE
borderStyledashed
titleAdvice and ExperienceborderStyledashed

AFAIK, Sakai already supports CAS authn. I enter this use case for two purposes: 1) there is potential to go beyond CAS authn to Sakai being merely possible, to make it a productized, polished, feature of the product. Enough schools need to do this that it seems worth producing the polished guide to doing it well.

2) Even if already implemented, this is an important use case to continue to consider as Sakai develops. Enterprise integration with Sakai is important to enabling other integrations.

...

Name <email>

Institution

Notes

Unlicensed Former user (Deleted)

Yale University

initial notes