Guides

Seamless Learning

Seamless Learning

Overview

Seamless Learning Access (SLA) is a Jamf capability for K-12 ed-tech partners. It signs students into your app on a managed iPad without a username, password, or tenant URL to type. Identity is brokered by the Seamless Learning Access app, and configuration is delivered through Apple's Managed App Configuration framework.

The process is explained more in this video:


📘

What you don't need to build

SLA does not require a Jamf-specific SDK, a Jamf-specific OIDC dialect, or any direct integration with RapidIdentity. From your app's perspective, this is a standard OIDC sign-in flow against an OIDC provider Jamf provisions for you once during Technology Partner onboarding. RapidIdentity happens to be the identity provider on the other end, but your iOS code never talks to it directly. The Seamless Learning Access app on the iPad handles all device-side communication with RapidIdentity.

The only Jamf-aware piece of your code is reading two keys (enableLogin and host) from your existing Managed App Configuration payload.

How the pieces fit together

sequenceDiagram
    actor Student
    box iPad
    participant App as Your App
    participant SLA as SLA SSO Extension
    end
    participant RI as RapidIdentity

    Student->>App: Opens app
    App->>App: Reads enableLogin and host from Managed App Configuration
    App->>SLA: OIDC Authorization Request (intercepted before leaving device)
    SLA->>RI: Completes OIDC exchange on the student's behalf
    RI-->>SLA: Tokens
    SLA-->>App: Authenticated session (standard OIDC tokens)
    App-->>Student: Signed in

The student opens your app. Your app reads enableLogin and host from its Managed App Configuration payload. If enableLogin is true, your app initiates a standard OIDC authorization request against your registered RapidIdentity issuer URL — the same kind of request it would make to any OIDC provider. The Seamless Learning Access SSO extension intercepts that request before it leaves the device, completes the OIDC round-trip with the appropriate district's RapidIdentity tenant on the student's behalf, and returns an authenticated session to your app. Once the student is authenticated, your app uses the host value to route them into the correct district's instance of your service. Your app sees the same kind of artifact at the end of this flow that it would see at the end of any normal user-driven OIDC sign-in.

Common partner questions

Do we need to create or manage student accounts?

No. Districts maintain student identities in RapidIdentity, sourced from Apple School Manager or their existing identity provider. Your app does not provision, store, or manage student accounts. When a new student signs in, their identity arrives in the OIDC token like any other federated user. Most apps create a local record just-in-time on first sign-in, the same pattern they'd use with any other IdP.

What student data does our app receive?

Whatever claims are released in the OIDC token, which is controlled by your OIDC client registration with RapidIdentity. The minimum standard release is a stable subject identifier and a UPN. Beyond that, you ask for what your app needs (display name, role, group memberships, and so on). SLA is the transport, not the policy.

Will our existing App Store users be affected?

No. When the enableLogin Managed App Configuration key is absent or false, your app should fall back to its normal sign-in flow. Only managed iPad devices in K-12 districts that have configured the App Config will be routed into the SLA path. Your consumer App Store experience is unchanged.

Does our backend need to talk to RapidIdentity?

Yes, but only at the server-to-server federation layer you'd already build for any OIDC IdP: discovery URL, client ID, scopes, token validation. Your iOS app never talks to RapidIdentity directly. The SSO extension handles all device-side communication with RapidIdentity transparently.

Is SLA about app distribution?

No. Jamf's MDM handles the distribution side (putting your app on the iPad). SLA is the authentication layer that signs students into your app silently once it's installed. The two are independent capabilities that work well together but are not the same thing.

Required app support

To integrate with Seamless Learning Access, your application must support the following:

  • OIDC sign-in — Your app must initiate a standard OIDC authorization request against the RapidIdentity issuer URL provisioned for you during Technology Partner onboarding. Authorization Code with PKCE is the recommended flow for public iOS clients. See the Seamless Learning Access Components page for client registration details.

  • Managed App Configuration — Your app must read configuration values that the MDM server delivers via Apple's Managed App Configuration framework. At minimum your app reads two keys, enableLogin and host. See Managed App Configuration Best Practices for the broader pattern and the Components page for the SLA-specific payload.

📘

Note

When enableLogin is false or missing, your app should fall back to its normal sign-in flow. This keeps your consumer App Store users unaffected by your Seamless Learning Access support.

What's next