Identity Management in Quercus Student Interaction. Simplified CampusIT_QUERCUS
Document information Document version 1.0 Document title Identity Management in Quercus Copyright 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. Identity Management in Quercus 2
Table of Contents 1 What is identity management?...4 1.1 The importance of identity why Quercus needs identity management...4 1.1.1 User privilege...4 1.1.2 User association...4 1.1.3 Summary: why your identity is important...4 1.2 How identity is established...4 1.3 What is an IDM?...5 2 Identity Management System components...6 3 LDAP... 7 3.1 LDAP entries...7 3.2 LDAP groups...7 3.3 Directory structure...7 3.4 Distinguished Names (DN)...8 3.5 Other names...8 3.6 Example...8 3.7 LDAP implementations supported in Quercus...8 3.8 The CampusIT Embedded option...8 3.9 External LDAP system or the CampusIT Embedded option?...9 3.9.1 Benefits of an external IDM (Identity Management System)...9 3.9.2 Drawbacks of an external IDM (Identity Management System)...9 3.10 External versus CampusIT Embedded...10 4 How Quercus uses the IDM...11 5 Configuring LDAP in Quercus...12 5.1 Integrating with an external LDAP server...12 5.2 LDAP parameters...12 5.3 List of LDAP parameters...13 5.4 Binding to LDAP...14 5.5 Explanation of LDAP parameters...14 6 Establishing the LDAP connection...18 6.1 Binding to LDAP...18 6.2 Note...18 6.3 Summary of steps...18 7 Example: Establishing the LDAP connection to a Microsoft Active Directory server...20 7.1 Note...20 7.2 Connect to the server and test the connection...20 7.3 Identify the Admin User in Quercus...22 7.4 Check the Admin User can authenticate to the LDAP server from Quercus...23 7.5 Enable SSL communication if required...23 7.5.1 Specify the location of the Oracle LDAP Wallet...24 7.5.2 Import the domain certificate into the Wallet...25 7.6 Specify the location of the LDAP user base...25 7.7 Link Quercus accounts with Active Directory LDAP accounts...25 7.7.1 Example of a user account...26 7.7.2 User Names...27 7.8 Set up LDAP groups...27 7.9 Test the installation...30 8 CampusIT Embedded...31 8.1 What is CampusIT Embedded?...31 8.2 Implementation details...31 8.2.1 APIs...31 8.2.2 Database tables...31 8.2.3 Passwords...31 8.3 Using CampusIT Embedded...31 8.4 Migration from CampusIT Embedded to an external IDM...32 9 Index...33 Identity Management in Quercus 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%99sguide/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: In the scenario where you log in directly to Quercus, Quercus establishes your identity by checking your user name and password against an internal table of usernames and password hash-values. Note: for security reasons Quercus does not store actual passwords in the table. 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. In other scenarios (which are described below) Quercus hands over the task of identity verification to an external identity management system. Identity Management in Quercus 4
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. Identity Management in Quercus 5
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). Identity Management in Quercus 6
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. 3.2 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 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 particular branches of the tree. Identity Management in Quercus 7
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: fwhite@campusit.org 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: 3.8 Apache Directory Server Microsoft Active Directory Novell edirectory OpenLDAP Oracle Internet Directory 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. Identity Management in Quercus 8
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. Identity Management in Quercus 9
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 User s level of privilege for each each individual system is upon common criteria (for example membership of a specific specific to the operation of the system in question (e.g. power division or office, role, seniority, location, etc.) 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 distributed across the technical team Poor understanding within the enterprise of IDM functionality or understanding confined to a small number of individuals Identity Management in Quercus 10
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 to reset a user password. Password is changed directly in the Quercus table. Change user permissions (Note 2) Quercus sends a request to the LDAP server to add 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 no need to make use of it. Identity Management in Quercus 11
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 administrator permissions and select Control Centre Set-Up. 2 Select Parameters. 3 Set the Namespace to Quercus System and the Group to Ldap and click Search. Identity Management in Quercus 12
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 5.3 Change the Value to the desired setting and click Save. 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 Identity Management in Quercus 13
5.4 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 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 You can leave this field blank when the LDAP server doesn t require authentication. LDAP_GROUP_BASE Purpose Specifies where the various LDAP groups (e.g. QP_STUDENT_EDIT, HESA_ADMIN) are located within the LDAP directory structure. If you create a new LDAP group, it will be located in the lowest level node of this path (in the example below, cn=groups) Identity Management in Quercus 14
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 URL or IP address. Identity Management in Quercus 15
LDAP_SERVER_PORT Purpose Specifies the port on which the LDAP server is communicating. Format Common values are 389 or 636, default is 389. 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). Quercus Menu applications and services which utilise LDAP lookups, must be able to link an LDAP user record with records for the same user within the Quercus Menu database. Identity Management in Quercus 16
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. Identity Management in Quercus 17
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. 4 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. Identity Management in Quercus 18
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. Identity Management in Quercus 19
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. 1 Set the server type using the LDAP_SERVER parameter in Quercus. Identity Management in Quercus 20
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. Identity Management in Quercus 21
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. This user can be located anywhere in the Active Directory. Identity Management in Quercus 22
7.4 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. 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. Identity Management in Quercus 23
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. 2 You must also enter the Wallet password. Identity Management in Quercus 24
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. Identity Management in Quercus 25
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 The screenshot shows the user record of James Gilbert in Quercus. Identity Management in Quercus 26
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. The groups are defined by Quercus and they need to be stored in a location in the Active Directory. Identity Management in Quercus 27
1 To identify the location of the groups, enter the group DN as the LDAP_GROUP_BASE parameter. The groups referenced in the DN above are shown below in the Active Directory. Identity Management in Quercus 28
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. Identity Management in Quercus 29
2 Add users to LDAP groups. You can do this: 3 through Quercus (as shown above) through Active Directory (as shown below) through batch scripts 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 You have now completed all the steps in the LDAP set-up procedure. You can now begin testing the installation. Identity Management in Quercus 30
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. 2 Set values for the following parameters: LDAP_ADMIN_USER_NAME Identity Management in Quercus 31
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 => 'admin@example.com', 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 8.4 Create a new user account (e.g. via the Apply Online service). 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. Identity Management in Quercus 32
9 Index A LDAP_WALLET_PASSWORD...17 Active Directory...20 admin user...18, 22 Apache Directory Server...8 attribute...7 M 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 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 groups...7 S I samaccountname...27 SAML...6 Service provider...6 Shibboleth...6 SSL...18, 23 SSL port...21 SSO...6 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 T telnet...22 U user privilege...4 userprincipalname...27 W Wallet...17, 24 Microsoft Active Directory server...20 Identity Management in Quercus 33