Identity Management in Quercus. CampusIT_QUERCUS

(1)

CampusIT

_

QUERCUS

Identity Management in Quercus

St

ud

en

t I

nt

er

ac

tio

n.

S

im

pl

ifi

ed

(2)

Document information

Document version 1.0

Document title Identity Management in Quercus

All rights reserved. No part of this document may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, recording, photocopying or otherwise outside of CampusIT Limited and without the prior permission of CampusIT Limited.

(3)

1 What is identity management?

1.1 The importance of identity – why Quercus needs identity management

“Hey John. Don’t I know your face, are ye Paddy Reilly or Brendan Grace, Are ye Mary Black or Freddie White?” says he.

Christy Moore – Welcome to the Cabaret

In order to function correctly, Quercus needs to know the identity of someone who wishes to use a particular service. By identity we simply mean who you are – are you John Anonymous, Mary Black, Freddie White or Christy Moore?

Your identity is of critical importance because it provides the link to your user profile. Your user profile stores a range of information about you including your level of user privilege and your association with particular courses or organisations.

1.1.1

User privilege

Your level of user privilege determines what actions you can and cannot perform and what services you can and cannot access. For example, if you have applied for a particular course you will be able to view the progress of your application but you will not be able to download course materials. If you are registered on the course you will be able to download materials and communicate with your tutor. If you are the tutor for the course you can upload course materials and enter marks for your students. If you are a course administrator you can add and delete tutors and students from the course.

In Quercus, user privilege is controlled through your membership of LDAP groups. Membership of a specific LDAP group conveys various privileges to group members. So, if you are a member of the OAPL_APPLICATION LDAP group you can access service requests received through Case Manager services; if you are a member of the

OAPL_SERVICE_ADMIN group you can set up and manage new student-facing Case Management services.

1.1.2

User association

Your association with with particular courses (or organisations), in combination with the Quercus security model, determines which information you are allowed to access. So, if the person security model is implemented, then you will only be able to view applications for the courses for which you are a tutor.

1.1.3

Summary: why your identity is important

Your identity is important because it allows Quercus to make the necessary judgements about what you can and cannot do and what information you can and cannot see. Quercus can do this because your identity is linked to a user profile which establishes your membership of LDAP groups and your association with courses and

organisations.

For more information see http://docs.campusit.net/publications/quercus-8.0.2.-control-centre-user%E2%80%99s-guide/security-options-and-control-centre-access

1.2 How identity is established

Quercus can use its own methods to establish a user’s identity or it can outsource this process to a third-party identity management management system. In practice this means:

(5)

1.3 What is an IDM?

An identity Management System or IDM is an application which centralises the authentication of users in situations where users need to access multiple applications within a corporate environment. Instead of each system having its own database of users, the individual systems make use of a central user database.

(6)

2 Identity Management System components

An identity management system is constructed from a number of components which can be deployed in various ways. The most commonly used components are described below.

Component Description

Service provider A service provider is a system which provides a service to the end-user. Quercus is a service provider in this sense.

Identity provider An identity provider is a system which can confirm the credentials of an authenticated user in response to a request from a service provider.

LDAP server Identity providers often take the form of LDAP servers.

LDAP (Lightweight Directory Access Protocol) provides a standard set of methods for referencing, storing and retrieving user profile information. LDAP databases can be thought of as large-scale dictionaries optimised for fast lookup of user profiles. What constitutes profile information can vary from organisation to organisation but generally includes name, contact details, organisation and role plus the membership of specific user groups known as LDAP groups.

SSO (Single sign on) SSO allows a user to log in once in order to gain access to all enterprise systems. Users enter their user IDs and passwords for one system and they are authenticated and signed in to all other systems to which they are authorised to access.

From the end-user’s perspective SSO provides the main visible benefit of a centralised IDM – just one log-in gives you access to all the enterprise systems you need.

Shibboleth Shibboleth is a widely used open source platform which can be used to enable the single-sign-on functionality and allow the sharing of user information between systems. Shibboleth is basically a set of server-side technological components which orchestrates the communication between an IDM LDAP server and the various systems which are in use.

Once you sign into a participating Shibboleth system you are authenticated to all other participating systems allowing you to navigate seamlessly from one system to another.

SAML The messages which Shibboleth passes between systems are encoded using SAML (Security Assertion Markup Language).

SAML provides a standard way of representing the authentication and authorisation messages which are passed between the identity provider (the LDAP server) and the service providers (of which Quercus is an example).

(7)

3 LDAP

3.1 LDAP entries

An LDAP directory holds the records of many users. The record of an individual user is known as an entry. Each entry is associated with a collection of attributes. An attribute has a name and one or more values.

Each LDAP directory has its own set of allowed attributes. These are defined in a schema. Typically attributes will be grouped into families such as general user details, address details, application accounts and so on.

A typical list of attributes is shown below.

Attribute Description

cn Name

c Business country

department Business department

givenname First name

homephone Home phone number

homepostaladdress Home postal address

info Notes

initials Initials

l Business city

mail Email address

mobile Home cellphone number

organizationname Company name

otherfacsimiletelephonenumber Home fax number

otherpager Business pager number

physicaldeliveryofficename Location of office at work

postaladdress Business postal address

postalcode Business postal code

sn Last Name

st Business state/province

telephonenumber Business phone number

title Job title

url Business web page

3.2 LDAP groups

In addition to storing user profile information, LDAP servers often store information about user groups. These groups are simply named entities. They are known as LDAP groups.

The LDAP server does not use the groups for any purpose it simply maintains the groups. The ‘meaning’ of the groups is determined by the various systems which use the IDM and the links between users and LDAP groups are held in these systems.

3.3 Directory structure

LDAP directories have a tree structure similar to the folder structure of a computer’s operating system. So entries can be subdivided to reflect the structure organisation. Specific operations can be allowed or disallowed for

(8)

3.4 Distinguished Names (DN)

Each LDAP directory entry has a unique identifier known as a Distinguished Name (DN). A DN specifies the position of an entry in the directory and is is similar, conceptually, to using a filepath as a unique resource identifier on a computer.

A DN is written left (most specific) to right (least specific) and looks something like this:

DN: uid=fwhite,ou=staff,dc=campusit,dc=org

However, because a DN may change when entries are moved within the tree structure, a user will also be uniquely identified (e.g. by the sAMAccountName or the userPrincipalName) in a way that provides a pointer to the user

record that is independent of the DN.

3.5 Other names

Within the LDAP structure there are several other conventionally used abbreviations: CN = Common Name

OU = Organizational Unit DC = Domain Component

3.6 Example

So combining the various names and attributes the record of a typical user might look something like this:

dn: cn=Freddie White,dc=campusit,dc=org cn: Freddie White givenName: Freddie sn: White telephoneNumber: +353 123 456 789 mail: [email protected]

manager: cn=Mary Black,dc=campusit,dc=org objectClass: inetOrgPerson

objectClass: organizationalPerson objectClass: person

objectClass: top

3.7 LDAP implementations supported in Quercus

Quercus supports the following LDAP implementations:

• Apache Directory Server

• Microsoft Active Directory

• Novell eDirectory

• OpenLDAP

• Oracle Internet Directory

3.8 The CampusIT Embedded option

In addition, Quercus has its own IDM-equivalent option known as CampusIT Embedded. CampusIT Embedded provides you with an alternative identity management solution if you do not want Quercus to be integrated with an external IDM. CampusIT Embedded allows you to set up and maintain LDAP users and LDAP groups in the same way that an external LDAP solution would, except that its use is confined to Quercus. CampusIT Embedded allows you to run Quercus as a totally standalone system without dependency on any external LDAP server.

(9)

3.9 External LDAP system or the CampusIT Embedded option?

Given that you have a choice between using an external LDAP option or the CampusIT Embedded option, which should you use?

3.9.1

Benefits of an external IDM (Identity Management System)

If an institution’s users regularly need to switch between applications supplied by different vendors it may result in the need to memorise a different login and password combination for each system. This requirement may confuse users, resulting in regular loss of passwords and imposing a corresponding load on support staff.

In addition, a centralised IDM removes the need to maintain the same data in several different systems, reducing data redundancy and increasing data quality.

3.9.2

Drawbacks of an external IDM (Identity Management System)

Centralised IDMs may be complicated to maintain as they introduce additional requirements for secure data transport and communication between systems.

In addition, a central IDM may introduce the single-point-of-failure for all enterprise systems should the IDM become unavailable.

(10)

3.10 External versus CampusIT Embedded

Before making the decision to delegate Quercus authentication to a centralised IDM, you will need to work out where the balance lies between the advantages and disadvantages listed above.

Factors favouring an external IDM Factors favouring the use of CampusIT Embedded

A typical user needs to access multiple enterprise systems Users tend to be associated with specific systems User’s level of privilege for each each individual system is based

upon common criteria (for example membership of a specific division or office, role, seniority, location, etc.)

User’s level of privilege for each each individual system is specific to the operation of the system in question (e.g. power user, content creator)

Users find it difficult to manage multiple logins and passwords Users are capable of managing multiple passwords and logins High volume of user profile data stored. Many of the systems

require access to the same nodes within this data set. Low volume of user profile data stored. Reliable established messaging infrastructure allowing data

transport between IDM and enterprise systems Messaging system infrastructure unreliable High availability of IDM can be guaranteed High availability of IDM cannot be guaranteed Good understanding within the enterprise of IDM functionality

(11)

4 How Quercus uses the IDM

Task in Quercus External CampusIT Embedded

Authenticate user (login) Quercus sends user name and password entered by user to LDAP server for verification.

It retrieves unique user ID to match username with the user record in the Quercus database.

User name and password is validated against data stored in a Quercus table.

Authorize user Quercus sends query to LDAP server to find

out if user is member of a particular group. Quercus queries a local table to find out if user is member of a particular group. Provision a new account Quercus sends a request to the LDAP server

to create a new user account.

Link between user account in LDAP and user record in Quercus is established via unique user id.

User account is provisioned directly in the Quercus table.

Reset or change user password

(Note 1) Quercus sends a request to the LDAP server toreset a user password. Password is changed directly in the Quercus table.

Change user permissions

(Note 2) Quercus sends a request to the LDAP server toadd or remove user from a specific LDAP

group.

User is added or removed from a group in the Quercu table.

Note 1: This feature is optional – for example, in a situation where a customer already has a global forgotten password service

there would be no need to make use of it.

Note 2: This feature is optional – for example, in a situation where a customer is using native LDAP tools exclusively there would be

(12)

5 Configuring LDAP in Quercus

5.1 Integrating with an external LDAP server

Quercus can be integrated with any of the five supported external LDAP implementations (Apache Directory Server, Microsoft Active Directory, Novell eDirectory, OpenLDAP and Oracle Internet Directory) by setting the appropriate parameter values in the Control Centre.

5.2 LDAP parameters

Quercus’s LDAP configuration is maintained by setting LDAP parameter values through the Control Centre.

Note: you must have the correct administrator-level permissions in order to access Control Centre and set the parameter values.

To locate LDAP parameters

1 Login to Assessments with adm

inistrator permissions and select Control Centre Set-Up.

2 Select Parameters.

(13)

To edit an LDAP parameter

1

Choose the parameter associated with the field you want to change and click

the corresponding edit icon

.

The Edit Parameter screen opens.

2 Change the Value to the desired setting and click Save.

5.3 List of LDAP parameters

The LDAP parameters are listed in the table below.

For a more detailed explanation of the parameters see Explanation of LDAP parameters, p.14.

For examples of how the parameters are set in a real configuration scenario see Example: Establishing the LDAP

connection to a Microsoft Active Directory server, p.20.

Parameter Description Namespace Value

LDAP_ADMIN_PASSWORD LDAP Admin Password Quercus System password LDAP_ADMIN_USER_NAME LDAP Admin User Name Quercus System DN, e.g.

cn=orcladmin,cn=users,dc=campusit,dc=net LDAP_GROUP_BASE LDAP Group Base Quercus System DN, e.g. cn=demo,cn=groups,dc=campusit,dc=net LDAP_NEW_USER_BASE LDAP New User Base Quercus System DN of location on LDAP server where Quercus

users created through the online application process are stored.

LDAP_PASSWORD_REMINDER LDAP Password Reminder Quercus System TRUE | FALSE

LDAP_SERVER LDAP Server Type Quercus System Apache Directory Server | CampusIT Embedded | Microsoft Active Directory | Novell eDirectory | OpenLDAP | Oracle Internet Directory LDAP_SERVER_HOST LDAP Server Hostname Quercus System IP address or Hostname of thr LDAP server LDAP_SERVER_PORT LDAP Server Port Quercus System Port on server.

Common values are 389 or 636, default is 389. LDAP_USER_BASE LDAP User Base Quercus System e.g. cn=DEMO,cn=Users,dc=campusit,dc=net

(14)

Parameter Description Namespace Value

LDAP_USER_ID_NUMBER LDAP User ID Number Quercus System an employee number

LDAP_WALLET LDAP Wallet Quercus System filepath of the location of the Oracle LDAP Wallet on the Quercus database server.

LDAP_WALLET_PASSWORD LDAP Wallet Password Quercus System password MSAD.LDAP_USER_NAME MSAD User Name

Attribute Quercus System legacy logon name PERSON_LDAP_MERGE Person LDAP Merge Quercus Global TRUE | FALSE

5.4 Binding to LDAP

The process of establishing a connection to the LDAP server is known as binding. When we take about linking Quercus to an LDAP server we refer to it as an LDAP bind.

5.5 Explanation of LDAP parameters

The following Control Centre parameters provide support for LDAP functions.

For examples of how the parameters are set in a real configuration scenario see Example: Establishing the LDAP

connection to a Microsoft Active Directory server, p.20.

LDAP_ADMIN_PASSWORD Purpose

Stores the LDAP server password for the defined admin user.

LDAP_ADMIN_USER_NAME Purpose

Specifies where the LDAP admin user is located within the LDAP directory structure.

Note: the specified user does not have to be an actual admin-level user — a user with sufficient access privileges to perform the lookups is sufficient for authentication and authorization. However, user account provisioning and management will requires additional system privileges.

In the example below cn=orcladmin is the lowest level node, dc=net the highest. A fragment of a corresponding

structure from an LDAP server is shown below.

Example

cn=orcladmin,cn=Users,dc=campusit-int,dc=net

(15)

Example

cn=Groups,dc=campusit-int,dc=net

In the above example cn=Groups is the lowest level node, dc=net the highest.

When the application searches for a group, it will only search in (and below) the path specified by this parameter. An example of a group node from an LDAP server is shown below:

LDAP_NEW_USER_BASE

A location in the directory structure where Quercus users created through the online application process are stored (allowing these users to be kept separate from long-term staff and student users). Not all institutions will use this option.

Note: this parameter is optional. When this parameter is left empty (default) new user accounts are created (provisioned) under the LDAP_USER_BASE.

LDAP_PASSWORD_REMINDER

If set to True, when users create new accounts through the Apply Online and Booking services they will be asked to select a password reminder question and answer. The users will be required to answer the security question as an additional security measure during the password reset process.

If set to False, the security question is not captured and is not required during password reset.

LDAP_SERVER

Set this to the type of LDAP server with which you are communicating. The options are:

• Apache Directory Server

• CampusIT Embedded

• Microsoft Active Directory

• Novell eDirectory

• OpenLDAP

• Oracle Internet Directory

LDAP_SERVER_HOST Purpose

Specifies the address of the LDAP server.

Format

(16)

LDAP_SERVER_PORT Purpose

Specifies the port on which the LDAP server is communicating.

Format

Common values are 389 or 636, default is ₃₈₉.

LDAP_USER_BASE Purpose

Specifies where, in the LDAP directory structure, the users are located. When the server receives an authentication request from Quercus the entry-search will be confined to this branch of the directory and any branches below it. For example:

If you create a new LDAP user, the record will be located in the lowest level node of this path (in the example below,

cn=QDOC)

Example

cn=QDOC,cn=Users,dc=campusit-int,dc=netn=Groups,dc=campusit-int,dc=net

In the above example cn=QDOC is the lowest level node, dc=net the highest.

When the application searches for a user, it will only search in (and below) the path specified by this parameter. An example of a user from an LDAP server is shown below.

LDAP_USER_ID_NUMBER

Purpose

Specifies the name of the LDAP property which links the LDAP user profile with the PERSON_LDAP.LDAP_ID field in Quercus Menu (see below).

(17)

This is done using the LDAP_USER_ID_NUMBER parameter.

Example employeenumber

LDAP_WALLET Purpose

Specifies the location of the Oracle LDAP Wallet.

The Oracle LDAP Wallet is a resource which stores the database’s authentication credentials, such as security certificates.

Format

Path to the Wallet.

If entered, must begin with file:

Leave blank when SSL communication is not required.

Example

file:d:\wallet

LDAP_WALLET_PASSWORD Purpose

Stores the password to the Oracle LDAP Wallet.

MSAD.LDAP_USER_NAME

In Microsoft Active Directory you can hold the user name in either the sAMAccountName or the userPrincipalName fields.

The MSAD.LDAP_USER_NAME parameter allows you to specify which field you are using. We recommend using the userPrincipalName rather than the sAMAccountName.

PERSON_LDAP_MERGE

Quercus has the capability to merge duplicate person (student) records. When this parameter is enabled, associated user accounts are merged as well. This is done by deleting one user account from the LDAP server and updating the other.

Depending on how accounts are provisioned within an institution this automation may not be desirable. When automated merging of user accounts is disabled Quercus will leave both user account intact. However, one account will no longer be linked to an existing person record in Quercus and should be removed by other processes.

(18)

6 Establishing the LDAP connection

6.1 Binding to LDAP

The process of establishing a connection to the LDAP server is known as binding. When we take about linking Quercus to an LDAP server we refer to it as an LDAP bind.

In order to establish an LDAP bind you will need to perform the following activities:

• connect to the LDAP server and test the connection

• specify the Admin User in Quercus

• check the Admin User can authenticate to the LDAP server from Quercus

• enable SSL communication if required

• specify the location of the LDAP user base

• link Quercus accounts with LDAP accounts

• set up LDAP Groups

The precise steps required to establish an LDAP connection to an external IDM will vary according to the LDAP server type to which you are connecting and your local Quercus environment.

In the next chapter we provide a detailed example of how these activities are executed when connecting to a Microsoft Active Directory server.

6.2 Note

The execution procedures required to establish an LDAP connection to an external IDM will vary according to the LDAP server type to which you are connecting and your local Quercus environment.

6.3 Summary of steps

An outline of the steps is given below. The next chapter provides a detailed example of how these activities are executed when connecting to a Microsoft Active Directory server.

Step Objective Summary

1 Connect to the server and test the

connection The first step is to enter the connection parameters in Quercus and then test that the connection actually works by telnetting from the Quercus environment to the LDAP server.

Note: The communication must be established from the Quercus database

server environment.

2 Identify the Admin User in Quercus If you wish to add users through services such as Apply Online you will require admin rights for writing to the LDAP directory. In order to perform the various read and write operations required in this scenario, Quercus must connect to the server as an admin user. To support this requirement you must enter details of the administrative user into Quercus.

3 Check the Admin User can authenticate

to the LDAP server from Quercus Once you have set up the admin user you should check that the user can authenticate to the LDAP server. You can use the Oracle SQL*Plus tool to perform this check.

(19)

Step Objective Summary 5 Specify the location of the LDAP user

base Now you have fully operative SSL communication between Quercus and the LDAP server you can specify the location of the Quercus users within the LDAP directory.

6 Link Quercus accounts with Active

Directory LDAP accounts Next, you must establish the link between the users in the LDAP directory and the users in Quercus. So if a user authenticates using LDAP and is granted access to Quercus, Quercus knows who that user is.

This link is maintained by using a field in the Quercus schema known as PERSON_LDAP.LDAP_ID. This field stores a unique LDAP identifier for each user which is compared to a corresponding unique identifier in the LDAP directory. Any suitable field holding a unique identifier can be used as the join field in the LDAP directory. For this reason it is necessary to specify which field is being used as the join using the LDAP_USER_ID_NUMBER parameter.

7 Set up LDAP Groups You have now established the user base and how Quercus users are joined to the LDAP server. At this stage student users can log into Quercus Gateway providing they are enrolled on a course instance

Back-end staff, however, must be member of LDAP groups for authorisation purposes. For this reason the Quercus LDAP groups must be set up on the LDAP server before staff members can authenticate and be authorised. The groups are defined by Quercus and they need to be stored in a location in the LDAP directory.

8 Test the installation You have now completed all the steps in the LDAP set-up procedure. You can now begin testing the installation.

(20)

7 Example: Establishing the LDAP connection to a

Microsoft Active Directory server

7.1 Note

The precise steps required to establish an LDAP connection to an external IDM will vary according to the LDAP server type to which you are connecting and your local Quercus environment.

This chapter provides a detailed example of how these activities are executed when connecting to a Microsoft

Active Directory server.

7.2 Connect to the server and test the connection

The first step is to enter the connection parameters in Quercus and then test that the connection actually works by telnetting from the Quercus environment to the LDAP server.

Note: The communication must be established from the Quercus database server environment.

(21)

2 Enter the address of the server using the LDAP_SERVER_HOST parameter. Enter a fully qualified name, the shortened name, or the IP address.

3 Enter the default port number.

Note: the default SSL port is 636 not 389.

4 Test your connection to the server.

In the example below we are sending the ping command from the database server (using PuTTY) to test the connection.

5 Once you have pinged the database server, telnet to the LDAP server to check that you can communicate from the database server to the Active Directory host.

(22)

Note: Many servers are configured not to respond to ping, so a ping failure is not a conclusive proof that the connection has not been established. For this reason you should attempt the telnet connection even if the ping has failed.

When establishing a telnet connection you will need to specify the port (the default telnet port 22 will not work).

In the screenshot below port 389 is used first to establish an open, unencrypted connection, followed by an encrypted connection over port 636.

Note: It is important you test your connections in the manner shown above, before moving on to set up the LDAP bind.

Now that you have established communication, you will need to authenticate as an admin user to the Active Directory.

7.3 Identify the Admin User in Quercus

If you wish to add users through services such as Apply Online you will require admin rights for writing to the LDAP directory. In order to perform the various read and write operations required in this scenario, Quercus must connect to the server as an admin user. To support this requirement you must enter details of the administrative user into Quercus.

1 Create, in Active Directory, an admin user who will be identified in Quercus and will act as the broker for all activities involving communication between the two applications.

This administrative user will have the necessary authorisation level to create, read, update and delete (CRUD) user records and LDAP groups within the Active Directories.

(23)

2 Enter details of the user into the LDAP_ADMIN_USER_NAME parameter in Quercus. Enter the distinguished name (DN) of the user.

3 Enter the admin password into the LDAP_ADMIN_PASSWORD parameter.

7.4 Check the Admin User can authenticate to the LDAP server from Quercus

Once you have set up the admin user you should check that the user can authenticate to the LDAP server. You can use the Oracle SQL*Plus tool to perform this check.

1 Set serveroutput to on and then execute the oc_ldap.ping command.

If successful, you should receive connection and authentication confirmation messages.

7.5 Enable SSL communication if required

If you plan to encrypt communication using SSL, you must provide Quercus with the relevant domain certificate for the LDAP sever. In the case of Active Directory, SSL mode is mandatory for all connections. Although it is not mandatory for other LDAP servers we recommend that it is used if at all possible.

(24)

7.5.1

Specify the location of the Oracle LDAP Wallet

1 To turn SSL on, specify the location of the Oracle LDAP Wallet.

The ‘Wallet’ is simply a named directory on the Quercus server in which certificates are stored.

See http://docs.oracle.com/cd/B28359_01/network.111/b28530/asowalet.htm#i1009041 for more information.

(25)

7.5.2

Import the domain certificate into the Wallet

1 Locate the domain certificate for the LDAP server and import the certificate.

See http://technet.microsoft.com/en-us/library/cc731014%28v=ws.10%29.aspx

Importing the certificate into the wallet automatically establishes SSL communication between the two servers.

If the wallet parameter is not filled in the system will operate in non-SSL (clear-text) mode.

7.6 Specify the location of the LDAP user base

Now you have fully operative SSL communication between Quercus and the LDAP server you can specify the location of the Quercus users within the LDAP directory.

1 To specify the user location enter the DN of the user base as the value of the LDAP_USER_BASE parameter.

Important: If users are are spread across different directories you must specify the common root for all the directories.

7.7 Link Quercus accounts with Active Directory LDAP accounts

Next, you must establish the link between the users in Active Directory and the users in Quercus. So if a user authenticates using Active Directory and is granted access to Quercus, Quercus knows who that user is.

This link is maintained by using a field in the Quercus schema known as PERSON_LDAP.LDAP_ID. This field stores a unique LDAP identifier for each user which is compared to a corresponding unique identifier in the Active Directory. Any suitable field holding a unique identifier can be used as the join field in Active Directory. For this reason it is necessary to specify which field is being used as the join using the LDAP_USER_ID_NUMBER parameter.

(26)

1 To identify the join field, enter its name in the LDAP_USER_ID_NUMBER parameter. In the example below the cn (common name) field is used as the join.

You can check the value of this field in Active Directory for any given user by using a tool such as Softerra LDAP Browser. In the example below the admin user’s cn (highlighted) is ‘admin’:

Once you have completed this step users should be able to log in.

Note: a user can only log into Quercus if he or she has a corresponding person account in Quercus.

Note: the admin user does not need a person account in Quercus.

7.7.1

Example of a user account

(27)

The screenshot below shows the same user record on the Active Directory server.

Note the join field: the cn in Active Directory, the LDAP ID in Quercus.

7.7.2

User Names

Note that in Active Directory you can hold the user name in either the sAMAccountName or the userPrincipalName fields.

You specify which name corresponds to the Quercus user ID via the MSAD.LDAP_USER_NAME parameter.

We recommend using the userPrincipalName rather than the sAMAccountName.

7.8 Set up LDAP groups

You have now established the user base and how Quercus users are joined to the LDAP server. At this stage student users can log into Quercus Gateway providing they are enrolled on a course instance.

Back-end staff, however, must be member of LDAP groups for authorisation purposes. For this reason the Quercus LDAP groups must be set up on the Active Directory server before staff members can authenticate and be authorised.

(28)

1 To identify the location of the groups, enter the group DN as the LDAP_GROUP_BASE parameter.

(29)

These groups are updated with each maintenance release of Quercus by various scripts (e.g.

ldap.quercus.sql, ldap.quercus.qlive, ldap.quercus.hesa) which use the oc_ldap API to create the required groups. Note that redundant existing groups are not deleted by these scripts.

Important: the admin user must always be added into an LDAP group. This is required to allow the Quercus administrator to add and remove LDAP groups from users. If the admin user was not added to an LDAP group it would not show up in the Available LDAP Groups pane below.

(30)

2 Add users to LDAP groups. You can do this:

• through Quercus (as shown above)

• through Active Directory (as shown below)

• through batch scripts

3 If you wish to separate Apply Online candidates from enrolled students within the LDAP server, complete the LDAP_NEW_USER_BASE parameter.

The parameter ensures that new users created via Apply Online will appear in a separate directory to the ‘full’ Quercus users (enrolled students and staff).

Note: the LDAP_NEW_USER_BASE must be below the LDAP_USER_BASE in the LDAP directory structure.

7.9 Test the installation

(31)

8 CampusIT Embedded

8.1 What is CampusIT Embedded?

CampusIT Embedded is Quercus’s own IDM-equivalent option. CampusIT Embedded provides you with an

alternative identity management solution if you do not want Quercus to be integrated with an external IDM. CampusIT Embedded allows you to set up and maintain LDAP groups in the same way that an external LDAP solution would, except that its use is confined to Quercus. CampusIT Embedded allows you to run Quercus as a totally standalone system without dependency on any external LDAP server. This is useful in situations when interoperability with other systems is not required and for training and test environments.

It can be also used when Oracle's DBMS_LDAP API is not available (e.g. in Oracle Database Cloud environments).

8.2 Implementation details

8.2.1

APIs

OC_LDAP and OC_LDAP_USER APIs were refactored to support new identity management type: CAMPUSIT_DB

8.2.2

Database tables

CAMPUSIT_DB is storing user credentials, attributes and roles in new QUERCUS tables: OC_LDAP_USER_STORE and OC_LDAP_USER_STORE_ATTRIBUTE.

8.2.3

Passwords

Passwords are stored securely – using a one-way secure hash (SSHA).

Note: for security reasons Quercus does not store actual passwords in the database. Only salt-protected one-way hash values are stored. This makes it impossible to retrieve what password is user using whilst still enabling the password to be validated.

8.3 Using CampusIT Embedded

To use CampusIT Embedded

1 Choose the CampusIT Embedded option from the LDAP_SERVER parameter.

(32)

• LDAP_PASSWORD_REMINDER

You do not need to set values for other LDAP parameters if you use the embedded option.

3 Set LDAP_ADMIN_USER_NAME to admin.

4 Go to Quercus Menu > Students and identify a person record.

5 Create a new admin account (as QUERCUS) by running the following script:

begin

-- create user: replace XXX with PERSON_LDAP.LDAP_ID oc_ldap_user.create_user( p_user_name => 'admin', p_password => '123456', p_email => '[email protected]', p_ldap_id => 'XXX', p_first_name => 'Joe', p_surname => 'Admin' ); -- add to groups oc_ldap_user.add_to_group('admin', 'QP_USER'); oc_ldap_user.add_to_group('admin', 'OAPL_USER_MANAGEMENT'); end; /

6 Re-create all LDAP groups by running all ldap.%.sql scripts from SU3800+\su3800\db\QUERCUS\data\config\static_data\)

Note: CAMPUSIT_DB stores list of all groups/roles by assigning them to the LDAP_ADMIN_USER_NAME user. If LDAP_ADMIN_USER_NAME is not pointing to an existing user account the list will be empty – making assignment of role in the Control Centre impossible.

7 Login to Quercus as admin

8 Test authentication, authorization and provision related functionality including:

9 Change user account attributes/roles in the control centre

10 Create a new user account (e.g. via the Apply Online service).

8.4 Migration from CampusIT Embedded to an external IDM

CampusIT Embedded has been designed in such a way that migration to an external IDM will be as simple as possible should it be required in the future. So the data structures within the Quercus database tables mirror those which would be found in an external LDAP IDM.

If you are using CampusIT Embedded and plan to move to an external IDM you should plan the migration with the assistance of CampusIT support.

Note: migration to the Microsoft LDAP server is somewhat more complicated than migration to other LDAP servers owing to the use of proprietary extensions in the Microsoft LDAP API and data model.

(33)

9 Index

A

Active Directory...20

admin user...18, 22 Apache Directory Server...8

attribute...7

B

bind...14, 18

C

CampusIT Embedded...8, 31

D

directories...7 Distinguished Name...8 domain certificate...25

E

Edit Parameter screen...13

employeenumber...17

G

groups...7

I

identity provider...6 IDM...5

L

LDAP bind...14 LDAP directories...7 LDAP groups...7, 19, 27 LDAP server...6

LDAP user base...25

LDAP_ADMIN_PASSWORD...14 LDAP_ADMIN_USER_NAME...14, 23 LDAP_GROUP_BASE...14, 28 LDAP_NEW_USER_BASE...15, 30 LDAP_PASSWORD_REMINDER...15 LDAP_SERVER...15, 20, 31 LDAP_SERVER_HOST...15 LDAP_SERVER_PORT...16 LDAP_USER_BASE...16, 25 LDAP_USER_ID_NUMBER...16, 25 LDAP_WALLET...17 LDAP_WALLET_PASSWORD...17

M

Microsoft Active Directory...8

migration...32 MSAD.LDAP_USER_NAME...17

N

Novell eDirectory...8

O

OpenLDAP...8

Oracle Internet Directory...8

Oracle LDAP Wallet...24

Oracle SQL*Plus...18, 23

P

parameter...13 PERSON_LDAP_MERGE...17 ping...21 port...16, 22 PuTTY...21

S

sAMAccountName...27 SAML...6 Service provider...6 Shibboleth...6 SSL...18, 23 SSL port...21 SSO...6

T

telnet...22

U

user privilege...4 userPrincipalName...27

W

Wallet...17, 24 Microsoft Active Directory server...20

Identity Management in Quercus. CampusIT_QUERCUS

CampusIT

_

QUERCUS

Identity Management in Quercus

St

ud

en

t I

nt

er

ac

tio

n.

S

im

pl

ifi

ed

Document information

Table of Contents

1

What is identity management?

1.1

The importance of identity – why Quercus needs identity management

User privilege

User association

Summary: why your identity is important

1.2

How identity is established

1.3

What is an IDM?

2

Identity Management System components

3

LDAP

3.1

LDAP entries

3.2

LDAP groups

3.3

Directory structure

3.4

Distinguished Names (DN)

3.5

Other names

3.6

Example

3.7

LDAP implementations supported in Quercus

3.8

The CampusIT Embedded option

3.9

External LDAP system or the CampusIT Embedded option?

Benefits of an external IDM (Identity Management System)

Drawbacks of an external IDM (Identity Management System)

3.10

External versus CampusIT Embedded

4

How Quercus uses the IDM

5

Configuring LDAP in Quercus

5.1

Integrating with an external LDAP server

5.2

LDAP parameters

inistrator permissions and select Control Centre Set-Up.

2

Select Parameters.

1

the corresponding edit icon

.

The Edit Parameter screen opens.

2

Change the Value to the desired setting and click Save.

5.3

List of LDAP parameters

5.4

Binding to LDAP

5.5