miniOrange JSM SSO Feature Guide

 2.1 Configure Portal Access

Admins can configure portal access in three different ways:

• Default (Jira-Based Access Control) — This setting respects the default Jira “Customer Access Permissions” and does not override any existing permissions. All projects have this setting enabled by default.
• Public (Unrestricted Access) — Allows all users to access the portal without any restrictions.
• Private (Restricted Access Based on Mapping) — Only users mapped via IDP Groups or Jira Organizations will have portal access.

Based on the screenshot, users belonging to the JSM organizations DevOrg and Org1 will only be able to access the Desktop Support portal, while users who are members of the IT_HelpDesk IdP group will only be able to access the IT Help Desk portal after successful authentication.

By setting the project type to Private, you can restrict JSM portal access based on JSM organizations or IdP groups. Only customers belonging to the specified IdP groups or JSM organizations are permitted to access that particular JSM project or customer portal — effectively enforcing customer portal restrictions based on JSM organizations and IdP group membership.

 2.2 Centralized Portal Access Control

Portal Access Mapping lets you control which customers can access which JSM projects — overriding the project's default customer permission settings.

As per the configuration shown below:

• Customer Support → Restricted to the Technical Support Team JSM Organization
• Development → Accessible to customers in the Developers JSM Organization or the SDE IDP Group
• Management → Restricted to the HR Department JSM Organization
• Remaining projects → Configure as needed using Organization, IDP Group, or Project Type

Project Type options:

All access rules are managed from a single centralized view — no need to configure each project individually within Jira.

 2.3 Use Case — Keycloak Role-Based Portal Access

To restrict customer access to specific Jira Service Management (JSM) portals based on Keycloak roles, roles can be fetched from Keycloak by configuring the group attribute in the SSO setup.

To retrieve the Role Attribute name, go to SSO Configuration, click Test Connection for the selected IdP, and review the attributes returned in the response. There, you will find the Role attribute name and its corresponding value like in the image shown below.

In the Organization Mapping configuration, these Keycloak roles can be treated as IDP groups and mapped to the relevant JSM organizations.

Subsequently, in Portal Access Mapping, the corresponding JSM organization or IDP group (Keycloak role) can be linked to specific JSM portals. This ensures that only authenticated customers with the defined Keycloak roles can access the designated portals, effectively preventing unauthorized portal access.

 3.1 Custom Field Attribute Mapping

The Custom Field Attribute Mapping feature allows Jira admins to map JSM custom fields with IDP attributes via an easy-to-use configuration panel.

Here’s how it works:

• When a customer logs into the JSM customer portal via SSO and initiates a request, all mapped custom fields will be automatically pre-filled with values retrieved from the customer’s IDP profile.
• This automation improves the speed, accuracy, and user experience of the request-raising process.
• Admins gain deeper visibility into request metadata without requiring manual input from the user.

 3.2 Support for Multiple IDPs and Attributes

In environments, an admin or JSM Agents may want to ensure that a custom field (e.g., Organization) is filled regardless of which IDP the user authenticated with.

To support this, the feature allows admins to set multiple IDP attributes to a single custom field. The add-on will sequentially evaluate the configured attributes and populate the field using the first matching attribute. This ensures flexible configuration for organizations with diverse IDP setups.

This feature empowers teams to:

• Eliminate redundancy
• Improve data accuracy
• Enrich request context with minimal effort
• Enhance user satisfaction and request processing efficiency

 3.3 Use Case — Eliminating Redundant Data Entry

Scenario:

A customer raises a support request through the Jira Service Management portal. The request form asks for the customer's name, email, and organization, fields that are already stored in the user's IDP profile.

How it Helps:

With the mapping feature enabled, the custom fields are automatically populated with values from the IDP attributes set in the custom field mapping tab, saving time and reducing the chance of errors.

 3.4 Use Case — Providing Additional Context to Admins

Scenario:

An enterprise offers different subscription models (Basic, Premium, Enterprise). Admins want to know the subscription level of the requester to prioritize and route the ticket accordingly.

How it Helps:

A custom field like Subscription Level can be mapped to an IDP attribute (e.g., idp_subscription_tier). When the request is raised, this field is auto-filled, giving the admin immediate visibility.

 3.5 Use Case — Role-Based Ticket Routing

Scenario:

Organizations often assign roles (e.g., Developer, Manager, Sales) to users in the IDP. Support requests might need to be routed or processed differently depending on the requester’s role.

How it Helps:

A custom field User Role is mapped to the idp_role attribute. Automation rules or workflows in Jira can categorize or assign tickets automatically based on the value of the field.

 3.6 Use Case — Instant Request Context for Support Agents

Scenario:

When a ticket is raised, agents often waste time tracking down basic requester information — switching between Jira and a separate HR system or directory just to identify who the person is, who their manager is, or which team they belong to.

How it Helps:

Custom fields like First Name, Employee ID, Manager, and Company Email are mapped directly to their corresponding IDP attributes. The moment a ticket is created, these fields are automatically populated with the requester's profile data — giving the agent full context on the ticket itself without any additional lookup.

 3.7 Use Case — Automated Manager-Based Approval Routing

Scenario:

Organizations require that certain requests — access requests, expense approvals, IT provisioning — are reviewed and approved by the requester's direct manager. Without IDP-to-Jira mapping, managers either have to be manually assigned on every ticket or hardcoded into workflows, which breaks the moment an org chart changes.

How it Helps:

The Manager custom field is mapped to the manager attribute in the IDP. Jira automation rules read this field at ticket creation and dynamically route the ticket to the correct approver — no manual assignment, no hardcoding. When the manager changes in the IDP, the routing updates automatically on the next sync without any workflow reconfiguration.