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 into the SFA System.

Access Student Financial Aid Via SSO and SAML

If your faculty and staff are logging 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 log 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 the Student Financial Aid System.

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 login) should be used for the NameID.
Note: A username created in SFA can't be the same as the username in the IDP that you are 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 user interface.

To enable institutions to invoke Single Sign On (SSO), Student Self-Service has a URL that can be exposed. When a user attempts to access the user interface, the user is redirected to the IDP system 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 the system 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)

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 may encounter:

  • No SP Session and No IDP Session

  • No SP Session but a Valid IDP Session

  • Valid SP Session

Login Scenario 1: No SP Session and No IDP Session

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

  2. SP generates the SAML request (e.g. 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 login 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 logged into the SFA application.


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

Login 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 (e.g. 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 logged into the SFA application.


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

Login Scenario 3: Valid SP Session

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

  2. SP identifies a valid session.

  3. User is logged into the SFA application.


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

Enable SSO-SAML 2.0

Once your environment(s) have been provisioned and you are ready to setup Single Sign On you need to log a Service Request (SR) for each environment (e.g. 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 may 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 will be able to 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 may 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 exist in Student Financial Aid System. But at a minimum, each role needs to exist to ensure unintended roles are not 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 of the 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 does not exist in SFA and none or only some of the 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 does not 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 Logout Management

When users are logged into Student Financial Aid they are in engaged in an active local application session. The local application session is invalidated upon a system logout. A logout 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.