How to test mod-login-saml

Owned by Steve Ellis
Last updated: Dec 04, 2023
3 min read

Mod-login-saml should be tested with every flower release. The purpose of this page is to document the testing procedure to supplement the guide that already exists in the module's readme files here. Also see the usage section of the main readme.

Glossary

IDP (identity provider) - The 3rd party that is providing authentication for the user.

Binding - They type of binding that the IDP provides. FOLIO supports both REDIRECT bindings and POST bindings.

See the module's guide for more glossary items.

Step-by-step guide

Testing mod-login-saml consists of the following general steps.

  1. Configure a mock IDP (SSO Circle or samltest.id).
  2. Configure FOLIO to use the mock IDP through the FOLIO UI. Go to Settings->Tenant->SSO settings in the FOLIO UI and fill in the fields, following the instructions in the guide for the parameters for each.
  3. Log out.
  4. Test the login by clicking on the SSO login button in the FOLIO UI. This button appears after SAML has been configured in step 2.

See the testing section of the guide for detailed instructions for configuring both mock REDIRECT and POST IDPs.

In step 4 you will now see the following button. This is what you want to press.
Once SSO is configured inside of the FOLIO UI you will see this button

Testing scenarios

The scope of testing has increased now that we are supporting refresh token rotation for SAML. This support was added in the Poppy release however front end support will not reach FOLIO until Q. This means that in Q, instead of testing only the two bindings (REDIRECT and POST) we need to test the two bindings for both RTR enabled mod-login-saml and non-RTR enabled mod-login-saml.

The four testing scenarios are documented in the following table.

Scenario

Stripes has RTR

Stripes configuration

Binding

Configuration required

Configuration

Mock IDP

Notes

1

True

useSecureTokens: true 

POST

Yes

Yes configuration is needed: SamlConfigRequest.callback = "callback-with-expiry"

SSOCircle

Configuration on backend is required because it is not the default. Stripes requires configuration.

2

False

useSecureTokens: false

POST

No

No configuration neededSSOCircle

No configuration on backend is required because this is the default for backend. Stripes requires configuration because its default is not to do RTR.

3

True

useSecureTokens: true 

REDIRECT

Yes

Yes configuration is needed: SamlConfigRequest.callback = "callback-with-expiry"samltest.id

Configuration on backend is required because it is not the default. Stripes requires configuration.

4

False

useSecureTokens: false

REDIRECT

No

No configuration needed

samltest.id

No configuration on backend is required because this is the default for backend. Stripes requires configuration because its default is not to do RTR.

A successful test for each scenario means that the user is able to login via the IDP via stripes without error and successfully make requests to the FOLIO back-end via stripes.

Configuration for RTR mode

When testing RTR mode (meaning, when running with RTR enabled), the callback endpoint needs to be configured by providing a SamlConfigRequest via PUT  to the saml/configuration  endpoint of the module. See the callback property of the schema here. The callback has two forms: callback  and callback-with-expiry . When the callback is configured as callback-with-expiry  the user will be provided an expiring token. When the callback is not configured, the callback will be callback  and the user will be provided an non-expiring access token.

Note, when UITEN-272 - Getting issue details... STATUS is complete there will be no need to configure the SAML callback via the API, since stripes will handle this configuration automatically.

It may help to be familiar with the changes for refresh token rotation. Adding support for refresh token rotation has increased the scope of what needs to be tested.