Case Study - PeopleSoft and SCIM

In this case study, we will explore how to think about implementing PeopleSoft as a SCIM Service Provider. This is a very high-level overview and is not a step-by-step guide. This is a guide to help you understand the concepts and how to think about implementing SCIM with some emphas on PeopleSoft. There is some information here that will help you understand the concepts and how to think about implementing SCIM.

We will also look at some design choices when implementing them in PeopleSoft. I have experience with OKTA with several clients and will use that as a reference point.

Introduction

SCIM (System for Cross-domain Identity Management) is a standard for automating the exchange of user identity information between IT systems. SCIM is designed to make managing user identities in cloud-based applications and services “easier.” SCIM is an open standard that is designed to simplify user management in cloud-based applications and services. SCIM is a standard that is defined by the SCIM specification. SCIM is not a product or a service. It is a set of rules and guidelines that determine how user identity information should be exchanged between systems.

That sounds complicated, but at its core, it allows for a “master” system to manage user accounts in cloud applications. In simpler terms, SCIM helps to automate keeping user information consistent across different systems. Imagine it as a universal “translator” for user data, ensuring everyone speaks the same language. This simplifies user management, improves security, and reduces administrative overhead.

The SCIM standard lays out some general rules for how user identity information should be exchanged between systems. This makes it easier for software vendors to support user account automation as it provides a starting point. Otherwise, each vendor would have to create their own custom solution for each system they want to integrate with and they would be drastically different from each other.

The SCIM standard is defined by the Internet Engineering Task Force (IETF) and is based on as few REST APIs.

• SCIM uses JSON messages to exchange user identity information between systems.
• SCIM defines a standard schema for representing user attributes like name, email, username, and group memberships.
• SCIM also defines a standard set of operations for creating, updating, retrieving, and deleting user accounts.

I think of SCIM as a “framework” to help design and implement user account management. It makes some decisions for you upfront, so you don’t have to reinvent the wheel.

Value of SCIM

Every company uses various online tools and apps – email, project management, file sharing, etc. Each time a new employee joins, someone has to create an account for them in each app manually. And when someone leaves, those accounts need to be deactivated. That’s a lot of work, right? Additionally, this list of applications is constantly changing.

In most corporate environments, this user account creation and sync is a mix of scripts, manual processes, and SFTP files, web service calls, manual help desk tickets. Every organization has some different process for managing this. It is often a Rube Goldberg machine of scripts and manual processes built over time.

No one is happy with their internal process and there is always room for improvement.

In my experience, SCIM is not widely used, but it is a good standard to know about and understand. SCIM is NOT a panacea nor a magic bullet for all your provisioning needs. It is a tool in the toolbox. Internal system experts still must do work to implement it. SCIM gives some structure to the process and helps to automate some manual work. If the cloud application you are trying to push users into supports SCIM, it can be pretty plug-and-play. However, if the application you are pushing users into does not, you will need to work with a developer in that system to accept SCIM messages and update the target systems.

I have implemented PeopleSoft to act as a SCIM Service Provider and Client. We will dig into some of my experiences and how to think about implementing SCIM in PeopleSoft.

What SCIM does NOT Solve

SCIM is a powerful tool for automating user management across applications and systems, but it’s not a silver bullet for all identity-related challenges. Here are some things SCIM does NOT solve for in a large corporation:

• Authentication: SCIM focuses on provisioning and managing user identities, not authenticating them. It doesn’t handle how users log in or prove their identity. You’ll still need solutions like SSO (Single Sign-On) and MFA (Multi-Factor Authentication).
• Fine-grained Authorization: While SCIM can handle essential role assignments, it doesn’t typically address complex, attribute-based access control or fine-grained permissions within applications. You’ll need more specialized authorization tools for that level of detail.
• Complex Workflow Automation: SCIM is primarily for user and sometimes group provisioning. It doesn’t inherently support complex approval workflows or automated processes beyond basic account creation and updates. You might need dedicated workflow management tools for those.
• Data Enrichment: SCIM typically deals with standard user attributes. It doesn’t automatically enrich user profiles with data from other sources, such as HR systems or social media. You’ll need separate integration or data enrichment solutions for that.
• Legacy Application Integration: Some legacy applications may not support SCIM and may require custom integration or alternative provisioning methods.
• Comprehensive Security Auditing: While SCIM facilitates user management, it doesn’t necessarily provide comprehensive audit trails or security monitoring capabilities. You’ll need dedicated security information and event management (SIEM) tools.
• Solving for “human factors”: SCIM can’t address issues like employees sharing accounts, poor password hygiene, or social engineering attacks. These require security awareness training and appropriate security policies.
• Data Mapping SCIM does not solve the problem of data mapping between systems. You still need to map the data between the source and target systems. This can be complex and time-consuming.

SCIM Implementation Overview

In the schematic below, you can see how SCIM could work. Here, we are modeling a fictitious university with two systems that manage HR and student data.

• The IDM needs to know what Employee accounts should be active and that can be sourced from the HR system with a SCIM message.

  • There are different ways to expose this data, and implementing a SCIM Service Provider in PeopleSoft is one way to do this. This would be for the HR Status of the employee.

• The IDM needs to know what student accounts should be active and that can be sourced from the Student system with a SCIM message. This is different than the security accounts (OPRID) that are created in the HR system.

  • Like HR there are different ways to expose this data, and implementing a SCIM Service Provider in PeopleSoft is one way to do this. The IDM system needs a data feed to know what Student accounts should be active and who recently graduated or left the university. This feed differs from the security accounts (OPRID) created in the Campus system.

• The IDM then can take data sent by both systems and create or update accounts in the IDM system.

• Then as a secondary step the IDM can send a SCIM message to the HR and Student systems to create or update accounts in those systems as well as any other systems that need to know about the new user.

• If the user is removed from the IDM system then the IDM can send a SCIM message to the HR and Student systems to remove the user account.

We are glossing over a lot of details here but this is a high-level overview of how SCIM could work.

Terminology

Maybe we should back up and introduce some terminology.

SCIM is about 2 systems talking to each other. One system is the SCIM Service Provider (SP), and the other system is the SCIM Client.

• SCIM Service Provider
  • The system that exposes the SCIM API (e.g., the /Users or /Groups endpoints).
  • Responsible for handling requests to manage resources (e.g., users, groups) and performing operations like creating, updating, retrieving, and deleting these resources.
  • This might be a cloud system like Zoom, Slack, or Salesforce.
• SCIM Client
  • The system that interacts with the SCIM Service Provider by sending API requests.
  • Often an Identity Provider (IdP) or another centralized system (e.g., Okta, Azure AD, Ping Identity) that manages user identities.

The client uses the SCIM APIs provided by the service provider to manage user identities. This will make more sense when we look at some examples later.

A SCIM message is a JSON message that is sent from the SCIM Service Provider to the SCIM Client. The SCIM message contains information about the user account that needs to be created, updated, or deleted. The SCIM message is sent over HTTP using the REST API.

Let’s look at a simple example of a fictitious Employee SCIM message.

{
  "schemas": [
    "urn:ietf:params:scim:schemas:core:2.0:User"
  ],
  "userName": "jdoe",
  "name": {
    "givenName": "John",
    "familyName": "Doe"
  },
  "displayName": "John Doe",
  "emails": [
    {
      "value": "jdoe@university.edu",
      "type": "work",
      "primary": true
    }
  ],
  "phoneNumbers": [
    {
      "value": "+1-555-123-4567",
      "type": "work"
    }
  ],
  "roles": [
    {
      "value": "Financial Aid Specialist",
      "type": "department"
    }
  ],
  "department": "Financial Aid",
  "organization": "University of Example",
  "title": "Financial Aid Officer",
  "active": true,
  "addresses": [
    {
      "type": "work",
      "streetAddress": "123 University Blvd",
      "locality": "Example City",
      "region": "State",
      "postalCode": "12345",
      "country": "USA"
    }
  ],
  "meta": {
    "created": "2024-12-07T10:00:00Z",
    "lastModified": "2024-12-07T10:00:00Z",
    "location": "https://scim.example.edu/Users/12345"
  }
}

The SCIM message contains information about the user account that needs to be created. The message contains the user’s username, name, email address, phone number, roles, department, organization, title, address, and other information. The message also contains metadata about when the user account was created and last modified.

The message structure has some standard parts and some ability to customize the message to fit your needs. The SCIM schema defines the message structure. The SCIM schema defines the structure of the message and the attributes that can be included in the message. The SCIM schema is a standard that is defined by the SCIM specification.

The client system can use GET requests to retrieve user information from the service provider system. The client system can use POST requests to create new user accounts in the service provider system. The client system can use PUT requests to update existing user accounts in the service provider system. The client system can use DELETE requests to delete user accounts in the service provider system. The client is acting as the orchestrator of the user accounts. So, the client generally has a scheduling system to know when to send messages to the service provider.

A few more terms to know:

• User: An individual who has an account in the IdP and potentially in the SP. SCIM defines a standard schema for user attributes like name, email, username, and group memberships.
• Group: A collection of users. SCIM allows groups to be created and managed in the IdP and for users to be assigned to these groups. This simplifies user management by allowing administrators to assign permissions and access rights to groups instead of individual users.
• Schema: A standardized definition of the format for user and group data. This ensures that the IdP and SP can understand and exchange information consistently. – Provisioning: The process of creating, updating, and deleting user accounts and group memberships in the SP, based on the data from the IdP. SCIM automates this process, reducing manual effort and errors.

PeopleSoft as a SCIM Service Provider

Since this book/website is about PeopleSoft, we will focus on some design choices and how to implement them in PeopleSoft.

Let’s imagine you are a University that uses OKTA as your Identity Provider.

• You have a PeopleSoft Campus Solutions system that manages your student data
• You have PeopleSoft HR system that manages your employee data.
• You have PeopleSoft Finance system that manages your financial data.
• You have different cloud systems that you use for different purposes.
  • Office 365 for email
  • Zoom for video conferencing
  • Slack for messaging
  • Salesforce for CRM
  • Zoho for project management and Help Desk
  • Brightspace for online learning
  • ADP for payroll
  • A home-grown system for training and development

That structure might look something like this:

Your organization might have the following automation needs:

• When a New Student is Admitted to the University:

  • Academic Data is entered into the Campus Solutions system, and a new Student account is created.
  • The needs for this new student might be:
    • An email account in Office 365
    • A bright space account
    • A Zoho account
    • A Campus Solutions self-service account
    • An account in the Dormitory system.

• When a new Faculty Member is Hired:

  • HR data is entered into the HR system, creating a new Employee account.
  • The needs for this new employee might be:
    • An email account in Office 365
    • A Zoom account
    • A Slack account
    • A Salesforce account
    • A Zoho account
    • A Campus Solutions self-service account
    • An account in the Financial system
    • A Self Service account in the HR system
    • A Self Service account in the Payroll System

• When a new Student Records Employee is Hired:

  • HR data is entered into the HR system, creating a new Employee account.
  • The needs for this new employee might be:
    • An email account in Office 365
    • A Zoom account
    • A Slack account
    • A Salesforce account
    • A Zoho account
    • A Campus Solutions self-service account
      • This account needs extra permissions to view student data, often called “Application Level Security” in PeopleSoft.
    • An account in the Financial system
    • A Self Service account in the HR system
    • A Self Service account in the Payroll System

Automating all of these account creations and updates is a lot of work. This is where SCIM can help. Again, SCIM is NOT a magic bullet but can help automate some manual work.

What are the first challenges that you might face when implementing SCIM in PeopleSoft?

Challenge 1: Data Mapping

First, you need to map out what the source systems are and what data they have?

• For Employees, you might have the following data:
  • Employee ID
  • First Name
  • Last Name
  • Email Address
  • Phone Number
  • Department
  • Job Title
  • Job Code
  • Location
  • Manager
  • Hire Date
  • Termination Date
  • Active Status
  • Employee Type
  • Employee Status
  • Employee Class
  • Employee Category

This employee data looks great and is a good start. However, the HR department generally designs many of these data elements around their own needs for managing employees and employee reporting and NOT around the needs of the other systems that need to know about the employee. What do I mean by this? If we take an employee who is an adjunct faculty member. HR might have this person flagged as a part-time employee with a Job Title of “Adjunct Faculty”. That is fine. However, when you start to get to automation you may find out that this data is not granular enough in some situations. For example, you might have 2,000 Adjunct Faculty members and some of your Colleges and Departments have access to different applications. The roles/groups in the target applications might differ based on the school and department they work for. HR may not have that detailed information because it was not required to pay the employee and issue a W2 at the end of the year. Some of that data might be in the Campus Solutions system that designates the employee as a faculty member in the College of Business who needs special access to some applications.

To further compound the situation, mergers, acquisitions, and reorganizations can make this data even more complex as it evolves and changes over time with a mix of old and new data elements.

• For Students, you might have the following data:
  • Student ID
  • First Name
  • Last Name
  • Email Address
  • Phone Number
  • Major
  • College
  • Class Level
  • Graduation Date
  • Active Status
  • Student Type
  • Student Status
  • Student Class
  • Student Category

The student data is structured around the needs of the Student system and not around the needs of the other systems that need to know about the student. The same issues that we discussed above for employees apply to students as well. It can get complex quickly.

Recommendations:

• Assemble a cross-functional team of internal experts who understand your internal systems and how they work together.
• Start with a data dictionary of the source systems and target systems.
• Map out the data elements that are common between the source and target systems.
  • Identify the data elements that are common between the source and target systems.
  • Identify the data elements that are unique to the source and target systems.
  • Identify the data elements that are missing from the source and target systems.
  • Identify the data elements that need to be transformed or combined to meet the needs of the target systems.

Challenge 2: Workflow Mapping

You then need to map out the workflows for how the data will flow between the systems.

• What actions in target systems will trigger SCIM messages?
• What actions should NOT trigger SCIM messages?
• Do you want real-time updates or batch updates? Most people think they want real-time updates, but there are times when real-time updates can actually cause issues. Has your HR department every accidentally promoted or terminated the wrong person with a similar name? Or they do something like terminate an employee but they end up rehiring them the next day into another business unit? Real-time updates could lock the employee out of systems that they need to do their job.
• If you start performing downstream automation based on system data you need to have a plan for how to handle data changes in the source systems. HR is often not aware that their data changes can cause downstream issues. For example, a new Department is added by Management and HR but IT is not aware of this change. This can cause downstream issues if you are driving distribution and security groups from that data. You need to have a plan for how to handle data changes in the source systems and a solid change control process to stay proactive.
• How do you handle promotions up and laterally where the employee may need to retain past permissions for some period of time while they are trained in their new role? Does your automation plan allow for one off exceptions or do need to build this into the process?
• Do you need to temporarily or permanently elevate accounts with data not in the source system? For example, you may have a faculty member who is also a department chair. The department chair role may not be in the HR system but you need to elevate their account in the target systems. How do you handle this? Developer accounts are another example of this.
• When a person is removed from an application, should their account be locked out or deleted? This is often a case by case decision. For example, if a student graduates you may want to lock their account out of the student system but keep their account active in the email system for a period of time.

Challenge 3: Gaps in Data

If we look at a system like PeopleSoft Campus Solutions there are additional areas of security outside just technical access security. There are also areas of security that are more about the data that the user can see and interact with. This is often called “Application Level Security” in PeopleSoft. This is a complex area of security that is often overlooked in SCIM implementations.

In finance systems, you might have “budget approvers” who can approve budgets for their department. This is not a technical security role but a data security role. SCIM does NOT handle this type of security. You need to have a plan for how to handle this type of security.

OKTA’s Value Proposition

In my experience working with OKTA at several organizations OKTA can help automate the user account management process.

• OKTA is the Identity Provider (IdP) and the source of truth for user accounts.
• OKTA ingests data from the HR system, Student system and other systems and combines different data elements into a single “Profile”.
• Rules are created in OKTA to determine what applications the user should have access to based on the data in the Profile.
• OKTA then sends SCIM messages to the target systems to create or update user accounts in those systems.
• As data changes in the source systems, OKTA sends SCIM messages to the target systems to keep the user accounts in sync.

OKTA accomplishes by using a Profile Master and then representing each application (i.e Cloud app) with a “Profile” that is a combination of data from the source systems. It allows mapping of attributes. As the data changes in the source system and is fed to the Profile Master the Profile is updated and then SCIM messages are sent to the target systems to keep the user accounts in sync. This is a very powerful concept and allows for a lot of flexibility in how you manage user accounts. It allows mapping of attributes. As the data changes in the source systems the Profile is updated and then SCIM messages are sent to the target systems to keep the user accounts in sync.

OKTA has ways to do straight mapping of the values to the source systems but also transform those mapping to concatenate values, split values, and do other transformations to the data. In some case, the target systems cannot handle SCIM but they may accept these attributes with “SAML Assertions” and some applications can provision and sync data from OKTA using SAML.

Service Provider Implementation

If you have gotten this far then you are ready to start designing the SCIM Service Provider APIs in PeopleSoft. A “Service Provider” is a system that exposes the SCIM API and accepts SCIM messages from the SCIM Client and updates security profiles. It is the system that is being updated by the SCIM messages.

This involves implementing some key REST Service Operations in PeopleSoft to handle the SCIM messages. Constructing the core service operations is not that complicated. The most complicated part is first parsing the JSON message and then mapping the data to the PeopleSoft objects. Of course, will be using CI according to best practices. You also have to handle the different types of SCIM messages that can be sent by the SCIM Client and make sure you are sending back the correct response codes and data. Since you are likely working with an IDP that is sending SCIM messages that sending system is likely expecting a certain response code and data back. That IDP system often cannot be changed to accommodate your system. You need to be able to handle the SCIM messages that are sent to you.

This is a high-level overview of the steps involved in implementing PeopleSoft as a SCIM Service Provider:

• Determine what API defined the SCIM Client is using:
  • You need to know what API the SCIM Client is using to send SCIM messages to the SCIM Service Provider.
  • Is the SCIM Client (IDP) sending SCIM 1.1 or SCIM 2.0 messages?
  • Is the SCIM Client (IDP) sending SCIM messages using GET, POST, PUT, or DELETE requests?
  • Is the SCIM Client (IDP) sending SCIM messages using the PATCH operation?
  • Is the SCIM Client (IDP) sending SCIM messages using the Bulk operation?
  • Is the SCIM Client (IDP) sending SCIM messages using the Change Password operation?
  • Is the SCIM Client (IDP) sending SCIM messages using the Service Provider Configuration operation?
  • Are you handling paginated results?
  • Are you handling filtering, sorting, and searching?
  • Are you handling error responses?
  • Are you pushing Roles and Groups definitions?
• Design the SCIM API:
  • Define the endpoints and operations that will be exposed by the SCIM Service Provider. This is generally 100% driven by what the SCIM Client is sending you and what use cases you are trying to solve.
  • I would recommend implementing your own logging on the PeopleSoft side as many IDPs do not have logging in a manner that is useful for troubleshooting.
  • I would recommend some retry logic in your code. Sometimes your code may error out for some reason and the IDP may not retry the message. You need to have a plan for how to handle this. If you log the message and the error you can then have a process that can retry the message.
• Implement the SCIM API:
  • Develop the REST service operations in PeopleSoft to handle SCIM messages. This involves parsing the JSON message, mapping the data to PeopleSoft objects, and performing the necessary operations (e.g., creating, updating, retrieving, deleting resources).
  • Implement the Component interface logic to handle the SCIM messages and update the security profiles and any other tables.
• Test the SCIM API:
  • Test the SCIM API to ensure that it can handle requests from the SCIM Client and perform the required operations. This includes testing the creation, updating, retrieval, and deletion of resources.

Conclusion

SCIM is a powerful tool for automating user management across applications and systems. It simplifies user management, improves security, and reduces administrative overhead. SCIM is not a silver bullet for all identity-related challenges, but it can help automate some manual work. SCIM is a standard that is defined by the SCIM specification and is based on REST APIs. SCIM uses JSON messages to exchange user identity information between systems and defines a standard schema for representing user attributes.