SSB9 Tech Stack: Step 1 ‐ User Authentication - Arch-Node/personal_studies GitHub Wiki

Back to SSB9 Tech Stack Overview

1.1 Overview

Ellucian Self-Service Banner 9 (SSB9) uses Single Sign-On (SSO) authentication to manage user access. The authentication flow ensures secure login and seamless access across the platform.

1.2 User Initiates Login

  • The user navigates to the Ellucian Self-Service URL (e.g., https://banner.university.edu/StudentSelfService).
  • The system checks for an active session.
  • If no session exists, the user is redirected to an authentication provider.

1.3 Authentication Methods

Ellucian supports various authentication protocols based on institutional preferences:

A. CAS (Central Authentication Service)

  • The user is redirected to a CAS server (https://auth.university.edu/cas/login).
  • The user provides username and password.
  • If valid, the CAS server issues a service ticket.
  • The ticket is validated by Banner, granting access.

B. SAML (Shibboleth, ADFS, Okta, Azure AD)

  • The user is redirected to a SAML Identity Provider (IdP).
  • The IdP validates the user credentials and issues a SAML assertion.
  • Depending on the institutional setup, the assertion may be validated by Ellucian Ethos Identity Service (optional) or handled internally.
  • If valid, Banner 9 grants access.

C. OAuth2 / OpenID Connect (OIDC)

  • The user is redirected to an OAuth2 provider (e.g., Azure AD, Google, Okta).
  • The provider authenticates and issues an access token.
  • The token is validated by Banner before access is granted.

D. Local Authentication (Legacy Banner Authentication)

  • Credentials are checked against GOBUMAP (User Mapping Table) in the Banner database.
  • Additional tables such as GOAFARS (Authentication Rules) and GOBEACC (User Access) may also be involved.
  • This method is primarily for internal or legacy authentication but is not recommended for production due to security concerns.

1.4 Session Creation & Token Handling

  • Upon authentication, a JWT (JSON Web Token) session is created.
  • The token is stored in a secure HTTP-only cookie or session storage.
  • Future requests include the token for authentication.
  • Example API call with authentication: 
    GET /api/student/advising/appointments
Authorization: Bearer {JWT_TOKEN}

1.5 Role and Permissions Validation

  • The system queries GURUSRI (User Security Table) for role-based access control.
  • Additional validation may involve GOBEACC to check access permissions.
  • Roles define user permissions (e.g., student, faculty, admin).
  • Unauthorized users are redirected to an access denied page.

1.6 Redirect to Self-Service Dashboard

  • If authentication is successful, the user is redirected to the dashboard.
  • The frontend (typically Angular/React or another JavaScript framework) loads data via API calls to display user-specific information.

Summary Flow

User → Authentication Provider (CAS/SAML/OAuth2) → Token Issued → Role Validation → Dashboard Access

Conclusion

SSB9 authentication ensures secure, role-based access to the system using industry-standard SSO protocols. The process integrates seamlessly with the frontend and backend, enabling a secure and efficient user experience.

Next Step: Go to SSB9 Backend API Step

Back: Back to SSB9 Tech Stack Overview