3 User Provisioning

The provisioning of users in the Oracle Student Learning (OSL) environment is primarily a technical concern. However, there is some overlap between user provisioning and functional administration. It is important that a functional administrator has a clear understanding of the provisioning process.

The Learning Tool (LT) can be deployed as a standalone application. However, a completely functional OSL environment requires integration with a content management system. As an enterprise application, OSL is typically deployed in a broader environment as part of the K-12 enterprise solution for learning and teaching. This could include other components such as portal, collaboration and communication tools, school administration systems, and so on.

It is for these reasons that:

• OSL requires external identity management (LDAP)

• Single sign-on (SSO) is a highly recommended component

• Users are not maintained in LT Admin

For information on integrating a content management system, see Chapter 5.

3.1 OSL and LDAP Attributes

Configuring LDAP and SSO to work with OSL is not within the scope of this guide. However, it is important to understand the relationship that the LDAP attributes have with OSL.

• OSL Party Identifier

  A user in OSL must have a Party Identifier that corresponds to the SSO id held in the LDAP directory. The Party Identifier should be a non-changing attribute that cannot be inferred from the user's name or other attributes. A State assigned number is an excellent candidate for the Party Identifier, whereas a personal email address is a poor candidate.

• LDAP User Groups

  A user must belong to a group in the LDAP directory corresponding to the user's role(s) in OSL. The default implementation of the LDAP groups are a direct mapping to the OSL roles as specified in Section 3.2 and articulated in the OSL Installation and Deployment Guide.

Regardless of the mechanism that is used to provision the users, ultimately users must be:

• added to the OSL database with their correct Party Identifier

• added to the LDAP directory with their correct Group assignments

3.2 User Roles

Users must be provisioned into OSL with an appropriate role. Users can have multiple roles. There are some roles that are used for two purposes.

3.2.1 LT Admin Roles

There are two types of administration roles: Department and School. Department roles are enterprise-wide, whereas School roles are in relation only to a specific school.

Table 3-1 LT Admin Roles

Role	Relationship
Department Administrator	Assign user roles, maintain Institutions, and preferences
Department Curriculum Administrator	Maintain Calendar, Curriculum Frameworks, and Graded Proficiency Sets
School Administrator	Assign user roles and maintain school-based preferences
School Curriculum Administrator	Maintain school curriculum, graded proficiency sets, courses, offerings, classes, and enrollments

3.2.2 LT Roles

A person may be defined as a STUDENT, TEACHER, or PARENT within the LT. The role definition is inferred through the person's relationships as specified in the table below.

Table 3-2 LT Roles

Role	Relationship
STUDENT	Requires a current "student" relationship to a school
TEACHERFoot 1	Requires a current "teacher" relationship to a school
PARENT	Requires a current "parental" relationship to a student

^Footnote 1 Any person defined in OSL as a "Teacher", which is typically inclusive of school principals and other support staff such as teacher's aides.