1. Implementing Student Financial Planning
  2. Integration of SAML 2.0 and SSO

Integration of SAML 2.0 and SSO

Student Financial Aid (SFA) uses SAML 2.0 SP-initiated SSO exchange to provide access (authentication and authorization) for client users to the SFA zpplication.

Access Student Financial Aid Via SSO and SAML

If your faculty and staff are signing into other web-applications through your enabled SAML 2.0 Identity Provider, you already know the identity of these users, so it only makes sense to use this information to sign them into the Student Financial Aid Cloud Service. Security Assertion Markup Language (SAML) enables a Single Sign-On (SSO) exchange and provides your institutions users access (authentication and authorization) to SFA.

Student Financial Aid uses the SAML 2.0 model where the Service Provider (SP) is defined as Student Financial Aid (SFA) and the Identity Provider (IDP) is defined as your Institution.

The Authentication Response SAML Assertion is sent by the IDP to the SP and contains necessary data about the user and the user authorization. The following attributes must be included in the SAML Assertion XML document:

  • FirstName

  • LastName

  • EmailAddress

  • Roles

Note: A unique identifier (usually the user sign in) should be used for the NameID.
Note: A user name created in SFA can't be the same as the user name in the IDP that you're using for SSO. In other words, the same account using the same set of identifiers can't exist in a single environment in both local and external form. But, a single environment can contain both local and external accounts with different identifiers for a unique user.

Access Student Self-Service Via SAML 2.0

The Student Financial Aid Student Self-Service supports Security Assertion Markup Language (SAML) based authentication to the UI.

To enable institutions to use Single Sign On (SSO), Student Self-Service has a URL that can be exposed. When a user tries to access the UI, the user is redirected to the IDP configured in Student Self-Service. The user is then authenticated into the IDP and redirected to the Student Self-Service with the proper authorization. Users entering the Self Service Ul via SAML, will not have to create separate SFA Self Service accounts, and will have access to all functions based on the role requested in their SAML assertion.

SAML assertion should contain these attributes, in addition to the (required) NameID. For information on managing SAML Attribute names, see Manage SAML Attribute Names:

  • FirstName (required)
  • LastName (required)
  • EmailAddress (optional)
  • PhoneNumber (optional)
  • Student ID:
    • Role: Student and Parent (required)
    • Role: Admin (optional)
  • Roles (required): Value can be any defined Role. For information on defining Roles, see Manage Role Permissions.

SAML/SSO integration allows the student or parent to access the Student Financial Aid Student Self-Service in the context of the student. The student's profile screen populates based on the values received in the SAML assertion message. It isn't necessary to create local student or parent accounts when accessing SFA via SAML.

When external users access Student Self-Service via SAML this user profile information is displayed upon successful authentication:

  • First Name
  • Last Name
  • Student ID
  • Email Address (if available)

Signed Authentication Requests

If your IDP application configuration is set for authentication requests to be signed, the SFA platform requires that the IDPSSODescriptor value within the IDP metadata you provide must include:

WantAuthnRequestsSigned="true".

This is applicable to new and update requests for Portal SAML/SSO configurations.

Authentication Scenarios

In the authentication functional flow the Service Provider (SP) is defined as Student Financial Aid (SFA) and the Identity Provider (IDP) is defined as your Institution.

There are three authentication scenarios users might see:

  • No SP Session and No IDP Session

  • No SP Session but a Valid IDP Session

  • Valid SP Session

Sign In Scenario 1: No SP Session and No IDP Session

  1. User tries to reach the Oracle application (SP).

  2. SP generates the SAML request (for example, AuthnRequest).

  3. SP redirects the browser to the configured IDP URL.

    1. Institution's Browser redirects the browser to the IDP URL.

  4. IDP authenticates user by presenting sign in form.

  5. IDP constructs SAML response.

  6. IDP returns SAML response to institution's browser.

    1. Institution's browser sends SAML response to SFA.

  7. SFA Assertion Consumption Service (ACS) verifies SAML response, auto provisions and auto syncs user & roles.

  8. User is signed into the SFA application.


This is a graphical representation of the functional flow when there's No SP Session and No IDP Session.

Sign In Scenario 2: No SP Session but a Valid IDP Session

  1. User tries to reach the Oracle application (SP).

  2. SP generates the SAML request (for example, AuthnRequest).

  3. SP redirects the browser to the configured IDP URL.

    1. Institution's Browser redirects the browser to the IDP URL.

  4. IDP identifies a valid session.

  5. IDP constructs SAML response.

  6. IDP returns SAML response to institution's browser.

    1. Institution's browser sends SAML response to SFA.

  7. SFA Assertion Consumption Service (ACS) verifies SAML response, auto provisions and auto syncs user & roles.

  8. User is signed into the SFA application.


This is a graphical representation of a functional flow when there's No SP Session but a Valid IDP Session.

Sign In Scenario 3: Valid SP Session

  1. User tries to reach the Oracle application (SP).

  2. SP identifies a valid session.

  3. User is signed into the SFA application.


This is a graphical representation of a functional flow when there's a Valid SP Session.

Enable SSO-SAML 2.0

Once your environment(s) have been provisioned and you're ready to setup SSO, log a Service Request (SR) for each environment (for example, Test, Stage, Production) and request IT setup the Financial Aid System (FAS) authentication redirect message. Because each Identity Provider and Service Provider need to agree upon the configuration for SAML, both ends need to have the exact configuration for the SAML authentication to work. You must also attach the IDP Metadata XML document to each SR. You can use a different IDP for accessing the FAS than you use for accessing Self Service.

Steps to Enable SSO-SAML 2.0

  1. Ensure the target environment has been provisioned and is ready to use.

  2. Go to My Oracle Support and create an SR titled Enable SSO-SAML 2.0 (environment) for each provisioned target environment.

  3. Include the IDP Metadata XML file (or link) in the SR.

  4. Include the IDP entityID (or link) in the SR

  5. Once Oracle Operations completes the SR, you can download the SP/SFA metadata.

  6. Update the environment_name in the following non-production/production links to download the SP/SFA metadata.

    1. Non-Production Link: https://sfp.ocs.oc-test.com/environment_name/vm-ui/saml/metadata

    2. Production Link: https://sfp.ocs.oraclecloud.com/environment_name/vm-ui/saml/metadata

Note: The IDP Metadata XML document is required for each environment as the attributes might be different from one environment to another.

Provisioning Scenarios

For users to be properly provisioned and synced, ideally the user and every role that can be mapped to a user should already exist in SFA, but at a minimum, each role needs to exist to ensure unintended roles aren't assigned to a user. To learn more about user and/or roles management, see:

User Management.

Create A New Role.

The following table provides common scenarios and their expected behaviors based on your school’s user and roles setup in Student Financial Aid (SFA).

Scenario Expected Behavior

User and all roles that should be mapped to the user exist in SFA.

  • User is retrieved from the SFA user record.

  • User is mapped to appropriate roles in SFA.

  • User attributes and user-role assignments are synced in SFA.

  • User session is initiated with SFA.

User exists in SFA, but none or only some roles that should be mapped to the user exist in SFA.

  • User is retrieved from the SFA user record

  • User is mapped to all existing roles in SFA.

  • User attributes and user-role assignments are synced in SFA.

  • User session is initiated with SFA.

User does not exist SFA, but all roles that should be mapped to the user exist in SFA.

  • User lookup by userId.

  • User not found, but user record is created.

  • User is mapped to the appropriate roles in SFA.

  • User session is initiated.

User doesn't exist in SFA and none or only some roles that should be mapped to the user exist in SFA.

  • User lookup by userId.

  • User not found, but user record is created.

  • User is mapped to all existing roles in SFA.

  • User session is initiated.

SAML assertion invalid/malformed.

  • User is denied access.

  • An integration error message is returned and displayed to the user.
Note:

  • This use case doesn't support the use of Transient Identifiers in NameId due to auto provisioning and syncing of the user.

  • SFA Internal Users are managed under a different namespace than the SAML Provisioned Users.

Session and Session Sign out Management

When users are signed into Student Financial Aid they're in engaged in an active local application session. The local application session is invalidated when a user signs out. A sign out is triggered either explicitly by the user or implicitly by a session timeout.

To change your session timeout setting, log a service request with Oracle Support.

Sample SAML XML Messages

You can download SFA Sample SAML XML Documents from Oracle Student Financial Aid Cloud Service: Integration Management 2514682.1 on My Oracle Support.