i-ready Support for Single Sign-On (SSO)

i-ready Support for Single Sign-On (SSO) Contents Benefits... 2 Supported Security Protocols... 2 How It Works... 2 SAML Workflow... 3 Clever Workflow... 4 Implementation Details... 5 Basic Assumption... 5 i-ready SSO Feature Options... 5 Clever Instant Login... 5 SAML... 5 Logout Link (optional)... 5 The SAML Assertion: Data Requirements... 6 NameID... 6 Required Attributes... 6 SSO Implementation Details... 8 SAML Implementation Process... 8 Implementation Questionnaire... 8

Benefits Fast, Secure Account Creation and User Authentication i-ready s Single Sign-On (SSO) feature enables administrators to control access to i-ready without the hassle of managing and maintaining a separate user account. For students and teachers, it provides streamlined access to i-ready without having to log in separately. Enhanced Security With Software-as-a-Service (SaaS) applications, maintaining control over logins can be challenging. i- Ready s SSO feature supports the most common security protocols used by identity providers. Reduced Help Desk Costs One of the most prevalent IT Help Desk incident types is users forgetting their password or having login difficulties. By enabling users to log in to i-ready (and other applications) through a single sign-on process, these requests are dramatically reduced. Supported Security Protocols i-ready supports the SAML 2.0 protocol. This provides optimum control over logins and permissions through its support of the most common security protocols used by identity providers. Almost all SSO implementations utilize SAML (Security Assertion Markup Language), an XML standard for exchanging authentication data between an identity provider (i.e., an SSO partner that vouches for the identity of a user) and a service provider (i.e., an SSO partner that provides services to an end user, such as i-ready). i-ready also has a partnership with Clever. This means if a school/district is using clever for data synchronization, sign-in can be simplified utilizing Clever s Instant Logon service. Clever is a registered trademark of Clever, Inc. How It Works When the user invokes i-ready with SSO enabled, i-ready generates a SAML request to the trusted identity provider (IDP). The user s identity, expressed as a SAML assertion or token, is transmitted back to i-ready. The SAML token is highly encrypted and signed with a security certificate, allowing i- Ready to decrypt the token s validity and authenticity. Using the information in the SAML token, i-ready grants access to the user. i-ready does not support service provider-initiated SSO. This means the user MUST sign in via their identity provider portal to log in to i-ready. Users are currently unable to access their IDP from i-ready s Login page. 2

SAML Workflow Per Figure 1 below, a typical SAML SSO request has the following flow: 1. The user logs on and authenticates with his or her network and applicable portal (ex. Classlink, Stoneware, etc.) 2. The user clicks a link to log in to i-ready from within their Identity Provider. 3. The IDP authenticates the user. 4. The IDP creates an encrypted SAML assertion or token. 5. The token is sent to i-ready s SSO Services. 6. The SSO Service makes a request to i-ready to authenticate the user. 7. i-ready responds with an AuthCode for the user. 8. If the attributes are correct, i-ready s SSO Service responds with the correct AuthCode. 9. The user can now use i-ready. Classlink is a trademark of Classlink, Inc. Stoneware is a trademark of Lenovo (Singapore) Pte. Ltd. Figure 1 3

Clever Workflow Per Figure 2 below, a typical Clever SSO request has the following flow: 1. The user logs in to the Clever Portal. 2. The user clicks a link to log in to i-ready from within their authentication portal. 3. Clever sends an access request to i-ready. 4. i-ready recognizes the account as a Clever account and responds with an Access Token Request. 5. Clever responds with the Receive Token. 6. i-ready requests the user information for login. 7. Clever responds with the user information and the user is now ready to log in. Figure 2 4

Implementation Details This section acts as an adjunct to the i-ready SSO Survey. The Survey acts as a preliminary review of a school s/district s SSO capabilities and helps i-ready evaluate the compatibility of SSO environments. Once the customer environment is determined compatible, this document should be reviewed to understand i-ready s SSO terminology and implementation options, the details of data exchange using the SAML assertion, and techniques for creating i-ready user accounts that are recognized by SSO. Basic Assumption The SSO operation ensures a highly secure authentication procedure. For SSO to operate properly, before accessing the i-ready site, the user must be logged into the customer s Identity Provider (IDP). i- Ready will communicate with the IDP to authenticate the requests made by the user. Users must be created in i-ready through our automated provisioning process. Users not created that attempt to authenticate will receive an error. Once SSO is enabled within i-ready, users will no longer be able to log in directly to i-ready with a username or password. It is imperative that administrators communicate with users to ensure a smooth transition process. i-ready SSO Feature Options There are two SSO options that must be considered. These options are specific to each environment and are meant to provide flexibility to accommodate the educator s User Experience requirement. Depending on the option chosen, a Logout link can be added to provide a smooth logout experience. Clever Instant Login This option determines if Clever will be used as the SSO IDP. Set-up is very simple as i-ready has a partnership trust with Clever allowing quick and easy set-up with little educator interaction. SAML This option is for all other implementations that use an IDP other than Clever for SSO. The IDP must be compatible with SAML2.0 and able to meet the metadata requirements below. Logout Link (optional) For a user who has accessed i-ready through SSO, should i-ready provide a Logout Link? If Yes, the school/district provides a URL where the user should be redirected. 5

The SAML Assertion: Data Requirements As stated above, the SAML assertion is expected to contain two sets of data: NameID A unique and persistent user identifier: This is the primary means for identifying users with i-ready. This is sometimes an SIS ID, State Student ID or other persistent unique identifier. This should be contained within the first element of the SAML Subject (NameID). NameID Format: This identifies the NameID format to be one of two options: transient or unspecified. Transient: This is meant to obfuscate the real user identity, so it s not possible to link user activities across different relying parties and is only valid for a single login session. Unspecified: This also obfuscates the real user identity and is meant to leave the implementation of the NameID format up to the identity provider. See the highlighted areas in the example below: <saml:subject> <saml:nameid Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" NameQualifier="wy-zmens17614" SPNameQualifier="i- Ready">UNIQUE_IDENTIFIER</saml:NameID> <saml:subjectconfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml:subjectconfirmationdata NotOnOrAfter="2015-08-14T17:22:34Z" Recipient="https://sso.i-Ready.com:443/auth/Consumer/metaAlias/sp" /> </saml:subjectconfirmation> </saml:subject> Required Attributes Role (optional): The educator can inform i-ready if the user is a teacher or student. This will be used to ensure that the chance of any duplicate IDs between roles (student having the same ID as a teacher) is mitigated. AccountID (required): The AccountID (provided by i-ready) determines the account in i-ready where users are located. State (optional): Used to specify the U.S. state for login. This field is optional. See the highlighted areas in the example below: <saml:attributestatement> <saml:attribute Name="accountId"> 6

<saml:attributevalue xmlns:xs="http://www.w3.org/2001/xmlschema" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:type="xs:string">wyzmens17614</saml:attributevalue> </saml:attribute> <saml:attribute Name="role"> <saml:attributevalue xmlns:xs="http://www.w3.org/2001/xmlschema" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:type="xs:string">student</saml:attributevalue> </saml:attribute> <saml:attribute Name="state"> <saml:attributevalue xmlns:xs="http://www.w3.org/2001/xmlschema" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:type="xs:string">wy</saml:attributevalue> </saml:attribute> </saml:attributestatement> 7

SSO Implementation Details SAML Implementation Process The steps below describe the end-to-end process of requesting, testing, and configuring SSO. 1. Request for SSO Setup is made and Support Case is created. 2. Initial call is scheduled. a. Discuss what to use for SSO (SAML/Clever). b. Is the Automated Provisioning method known (for new districts)? c. Discuss attributes necessary for SAML SSO (AccountID, role, etc.) 3. SSO testing environment metadata is sent to educator (and can be downloaded here). 4. Educator sets up a test SSO application in their Identity Provider/Portal. 5. Educator sends application metadata to i-ready. 4. Educator metadata imported to the SSO testing environment. 6. SSO testing environment is configured for SSO. 7. Testing is performed. a. Ensure SAML assertion contains proper attributes. b. Ensure users can log in via SSO. c. Login experience is verified. 8. Once testing is complete, production metadata is sent to educator. 9. Educator re-imports production metadata. 10. i-ready imports the educator s metadata to production environment. 10. SSO is enabled in production on the go-live date. Implementation Questionnaire The following questionnaire serves as the basis for pre-implementation discussions between your district leadership, IT organization and i-ready. Several of the checklist items require all parties be present on the discussion because business decisions may influence the technical implementation (and vice versa). Your Identity Provider must support SAML 2.0 to properly implement SSO with i-ready. What Identity Provider will be used to implement SSO? Describe the SSO user experience desired (e.g., user logs into district portal; clicks the i-ready link, etc.) Please provide the metadata for the SAML Application. (Can be sent separately) Please review the SAML Assertion data requirements above (pages 6 7). Indicate that 8

these items will be provided as specified. Please indicate any discrepancies (in detail). Please tell us your desired go-live date: Please enter the Logout URL to which i-ready should redirect users upon logging out: 9