Difference between revisions of "Development/Functional testing/Single sign-on (CAS) tests"
(→About) |
|||
| (One intermediate revision by the same user not shown) | |||
| 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. | 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:// | + | 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). | 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. | Given: The institution hosting AtoM is running a CAS server. | ||
| + | |||
And: The user has an active CAS account. | And: The user has an active CAS account. | ||
| + | |||
And: The user account is present in the AtoM group member list on the CAS server. | 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. | 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. | 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: 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: 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: 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 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 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: 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. | 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 | 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 | 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 | Then: The user is still able to log-in using their CAS account and their AtoM account is re-created | ||
Latest revision as of 16:17, 9 September 2020
Main Page > Development > Development/Functional testing > Development/Functional testing/Single sign-on (CAS) tests
About
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://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).
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