Development/Functional testing/Single sign-on (CAS) tests - Revision history

Dan: Add category and navigation footer

2025-07-01T12:18:35Z

Add category and navigation footer

PeterVG: /* About */

2020-09-09T22:17:24Z

‎About

PeterVG: /* Single sign-on login */

2020-09-09T22:14:37Z

‎Single sign-on login

PeterVG at 22:11, 9 September 2020

2020-09-09T22:11:15Z

PeterVG at 22:06, 9 September 2020

2020-09-09T22:06:21Z

PeterVG at 22:05, 9 September 2020

2020-09-09T22:05:17Z

PeterVG at 22:04, 9 September 2020

2020-09-09T22:04:37Z

PeterVG: Created page with "Centralized Authentication Service (CAS) is an enterprise single sign-on protocol that can be implemented by enabling the arCasPlugin and registering accounts with a CAS serve..."

2020-09-09T21:58:51Z

Created page with "Centralized Authentication Service (CAS) is an enterprise single sign-on protocol that can be implemented by enabling the arCasPlugin and registering accounts with a CAS serve..."

New page

Centralized Authentication Service (CAS) is an enterprise single sign-on protocol that can be implemented by enabling the arCasPlugin and registering accounts with a CAS server.

See https://www.apereo.org/projects/cas.

← Older revision		Revision as of 12:18, 1 July 2025
Line 47:		Line 47:

	Then: The user is still able to log-in using their CAS account and their AtoM account is re-created		Then: The user is still able to log-in using their CAS account and their AtoM account is re-created
		+
		+
		+
		+	------
		+
		+	* [[Development/Functional_testing\|Back to Functional testing]]
		+	* [[Development\|Back to Development]]
		+	* [[Main Page\|AtoM wiki home]]
		+
		+	[[Category:Development documentation]]

@@ Line 5: / Line 5: @@
 Centralized Authentication Service (CAS) is an enterprise single sign-on protocol that can be implemented in AtoM by enabling the arCasPlugin and by registering user accounts with a CAS server. For more about CAS see https://www.apereo.org/projects/cas.
-For testing purposes, a public CAS demo server can be used. See https://django-cas-ng-demo-server.herokuapp.com/cas/) s. The username ''admin'' and the password ''django-cas-ng'' can be used to authenticate on the demo server.
+For testing purposes, a public CAS demo server can be used. See https://python-cas-flask-example.herokuapp.com/. The username ''admin'' and the password ''django-cas-ng'' can be used to authenticate on the demo server.
 The arCasPlugin also provides an optional mechanism for dynamically setting AclUserGroup membership on each login, based on the presence or absence of expected values in the attributes returned from the CAS server during p3/serviceValidate (CAS version 3.0 only).

@@ Line 14: / Line 14: @@
 Given: The institution hosting AtoM is running a CAS server.
 And: The user has an active CAS account.
 And: The user account is present in the AtoM group member list on the CAS server.
 When: The user starts a new session on the institution’s domain and navigates to an AtoM page that requires authentication.
 Then: The unauthenticated user is redirected to the CAS login form where they enter their CAS username and password.
 And: The CAS server successfully authenticates the user, assigns them a session service ticket, and redirects them to the AtoM server.
 And: AtoM sends the service ticket to the CAS server over HTTPS for validation.
 And: The CAS server sends a success response to AtoM which includes the user attributes set on the CAS server.
 And: AtoM creates a new user account if one matching the CAS account doesn’t already exist.
 And: AtoM sets the user session cookie (with the service ticket stripped off) and redirects the user to a new, authenticated AtoM session.
 And: AtoM checks its configuration file to see if there are expected CAS attributes for user groups. If so, AtoM checks whether the user has the appropriate attribute for a given group and elevates their user authorization to become an authenticated member of one or more of these groups if this is the case (e.g. editor, translator, administrator).
 And: When the user logs out of AtoM, they will also be automatically logged out of CAS.
 Given: A user account is created on the CAS server and the user has logged into AtoM
 When: An AtoM administrator user deletes that user account in AtoM
 Then: The user is still able to log-in using their CAS account and their AtoM account is re-created

← Older revision		Revision as of 22:11, 9 September 2020
Line 8:		Line 8:

	The arCasPlugin also provides an optional mechanism for dynamically setting AclUserGroup membership on each login, based on the presence or absence of expected values in the attributes returned from the CAS server during p3/serviceValidate (CAS version 3.0 only).		The arCasPlugin also provides an optional mechanism for dynamically setting AclUserGroup membership on each login, based on the presence or absence of expected values in the attributes returned from the CAS server during p3/serviceValidate (CAS version 3.0 only).
		+
		+	==Single sign-on login==
		+
		+	Test scenario: A user is authenticated through a Central Authentication Service (CAS) single sign-on form and is automatically logged in to an AtoM session.
		+
		+	Given: The institution hosting AtoM is running a CAS server.
		+	And: The user has an active CAS account.
		+	And: The user account is present in the AtoM group member list on the CAS server.
		+	When: The user starts a new session on the institution’s domain and navigates to an AtoM page that requires authentication.
		+
		+	Then: The unauthenticated user is redirected to the CAS login form where they enter their CAS username and password.
		+	And: The CAS server successfully authenticates the user, assigns them a session service ticket, and redirects them to the AtoM server.
		+	And: AtoM sends the service ticket to the CAS server over HTTPS for validation.
		+	And: The CAS server sends a success response to AtoM which includes the user attributes set on the CAS server.
		+	And: AtoM creates a new user account if one matching the CAS account doesn’t already exist.
		+	And: AtoM sets the user session cookie (with the service ticket stripped off) and redirects the user to a new, authenticated AtoM session.
		+	And: AtoM checks its configuration file to see if there are expected CAS attributes for user groups. If so, AtoM checks whether the user has the appropriate attribute for a given group and elevates their user authorization to become an authenticated member of one or more of these groups if this is the case (e.g. editor, translator, administrator).
		+	And: When the user logs out of AtoM, they will also be automatically logged out of CAS.
		+
		+	Given: A user account is created on the CAS server and the user has logged into AtoM
		+	When: An AtoM administrator user deletes that user account in AtoM
		+	Then: The user is still able to log-in using their CAS account and their AtoM account is re-created

@@ Line 3: / Line 3: @@
 ==About==
-Centralized Authentication Service (CAS) is an enterprise single sign-on protocol that can be implemented by enabling the arCasPlugin and by registering user accounts with a CAS server. For more about CAS see https://www.apereo.org/projects/cas.
+Centralized Authentication Service (CAS) is an enterprise single sign-on protocol that can be implemented in AtoM by enabling the arCasPlugin and by registering user accounts with a CAS server. For more about CAS see https://www.apereo.org/projects/cas.
-For testing purposes, a public CAS demo server can be used. See https://django-cas-ng-demo-server.herokuapp.com/cas/) s. The username/pw combo admin / django-cas-ng can be used to authenticate on the demo server.
+For testing purposes, a public CAS demo server can be used. See https://django-cas-ng-demo-server.herokuapp.com/cas/) s. The username ''admin'' and the password ''django-cas-ng'' can be used to authenticate on the demo server.
 The arCasPlugin also provides an optional mechanism for dynamically setting AclUserGroup membership on each login, based on the presence or absence of expected values in the attributes returned from the CAS server during p3/serviceValidate (CAS version 3.0 only).

← Older revision		Revision as of 22:05, 9 September 2020
Line 1:		Line 1:
−	{{#pagetitle: ~~Admin~~ tests }}	+	{{#pagetitle: Single sign-on (CAS) tests }}
	[[Main Page]] > [[Development]] > [[Development/Functional testing]] > Development/Functional testing/Single sign-on (CAS) tests		[[Main Page]] > [[Development]] > [[Development/Functional testing]] > Development/Functional testing/Single sign-on (CAS) tests

← Older revision		Revision as of 22:04, 9 September 2020
Line 1:		Line 1:
−	~~Centralized Authentication Service (CAS) is an enterprise single~~ sign-on ~~protocol that can be implemented by enabling the arCasPlugin and registering accounts with a~~ CAS ~~server.~~	+	{{#pagetitle: Admin tests }}
		+	[[Main Page]] > [[Development]] > [[Development/Functional testing]] > Development/Functional testing/Single sign-on (CAS) tests

−	~~See~~ https://www.apereo.org/projects/cas.	+	==About==
		+	Centralized Authentication Service (CAS) is an enterprise single sign-on protocol that can be implemented by enabling the arCasPlugin and by registering user accounts with a CAS server. For more about CAS see https://www.apereo.org/projects/cas.
		+
		+	For testing purposes, a public CAS demo server can be used. See https://django-cas-ng-demo-server.herokuapp.com/cas/) s. The username/pw combo admin / django-cas-ng can be used to authenticate on the demo server.
		+
		+	The arCasPlugin also provides an optional mechanism for dynamically setting AclUserGroup membership on each login, based on the presence or absence of expected values in the attributes returned from the CAS server during p3/serviceValidate (CAS version 3.0 only).