#2335 Portal Users Cannot Access REST API Despite Having Valid Personal Tokens
Summary
Portal users are blocked from accessing the REST API even when they have valid personal tokens with REST/JSON scope and meet all configuration requirements. This contradicts iTop’s personal tokens documentation which allows Portal users to create REST tokens.
Environment
iTop version: 3.2.2-1 (likely affects all versions with personal tokens support)
Component: REST API / Authentication
Type: Defect / Feature Request
Priority: Medium
Files affected:
webservices/rest.php (line 103)
application/loginwebpage.class.inc.php (line 1007)
Configuration
All required configuration settings are properly configured:
'allowed_login_types' => 'form|external|basic|token',
'allow_rest_services_via_tokens' => true,
'secure_rest_services' => false,
'authent-token' => array(
'personal_tokens_allowed_profiles' => array(
'Portal user',
'Service Desk Agent',
'Administrator',
),
),
Problem Description
Current Behavior
When a Portal user (or any user with the Portal user profile) attempts to access the REST API using a valid personal token, they receive:
{"code":1,"message":"Error: Portal user is not allowed"}
This occurs even when:
- The user has a valid personal token with REST/JSON scope
- The user has additional backoffice profiles (e.g., Service Desk Agent)
- All configuration parameters are correctly set
- The token works fine for users WITHOUT the Portal user profile
Expected Behavior
Portal users with valid personal tokens should be able to access the REST API, restricted by their existing data permissions (same as in the UI).
Root Cause
The blocking occurs at two levels:
- REST API endpoint (webservices/rest.php line 103):
$iRet = LoginWebPage::DoLogin(false, false, LoginWebPage::EXIT_RETURN);
The second false parameter ($bIsAllowedToPortalUsers) explicitly denies portal users.
- Login authentication logic (application/loginwebpage.class.inc.php line 1007):
$sRequestedPortalId = $bIsAllowedToPortalUsers ? 'legacy_portal' : 'backoffice';
Even when $bIsAllowedToPortalUsers = true, it requests ‘legacy_portal’ which triggers portal dispatch validation that fails for certain profile combinations.
Relation to Previous Ticket #1530
I’m aware of ticket #1530 where this restriction was marked not-a-bug due to security concerns. Vincent from Combodo explained that allowing portal users REST API access could bypass portal scope restrictions, potentially letting them read, modify and delete any object.
However, the context has changed significantly since 2018:
Why This Should Be Reconsidered as a Feature Request
1. Personal Tokens were introduced after ticket #1530: The authent-token extension with profile-based restrictions wasn’t available in 2018. Personal tokens address the original security concerns by:
* Inheriting user’s existing data permissions
* Supporting scoped access (REST/JSON scope)
* Using the same authorization system as the UI
* Allowing per-profile token restrictions via personal_tokens_allowed_profiles
2. Documentation now suggests Portal user support: The current official personal tokens documentation (https://www.itophub.io/wiki/page?id=extensions:authent-token) explicitly allows Portal users to create REST/JSON tokens, but they cannot actually use them due to the hardcoded restriction
3. Security is maintained with Personal Tokens: Unlike basic authentication (which was the concern in #1530), personal tokens:
* Don’t bypass portal scopes
* Use the same permission checks as the UI
* Are restricted to user’s existing data access
* Can be revoked individually
* Have expiration dates
* Can be limited by profile via configuration
4. Configuration implies this should work: personal_tokens_allowed_profiles can include ‘Portal user’, suggesting intended support, but the hardcoded check in rest.php prevents it
5. No additional security risk: A portal user with a REST token has the exact same data access as using the portal UI - no new permissions are granted
6. Valid modern use case: Portal users integrating with third-party tools (mobile apps, file storage systems, custom dashboards) for self-service is now a standard business requirement
The Core Issue
The security concern in ticket #1530 was valid for basic authentication but personal tokens fundamentally solve that problem. The current situation creates a contradiction:
- iTop allows Portal users to create REST tokens ✅
- iTop documents how Portal users can create REST tokens ✅
- iTop configuration supports restricting Portal user tokens ✅
- But Portal users cannot actually use those tokens ❌
Steps to Reproduce
- Create a Portal user (or add Portal user profile to existing user)
- Ensure user is in personal_tokens_allowed_profiles configuration
- Log into iTop Portal as this user
- Navigate to My Profile → Personal API Tokens
- Create a new token with REST/JSON scope
- Attempt to use the token with REST API: bash curl --location -g --request POST \ 'https://your-itop.com/webservices/rest.php?version=1.3&json_data={"operation":"list_operations"}' \ --header 'Auth-Token: YOUR_TOKEN'
- Observe the error: Portal user is not allowed
Proposed Solution
Option 1: Configuration Parameter (Recommended for backward compatibility)
Add a new configuration parameter to make this behavior opt-in:
'authent-token' => array(
'personal_tokens_allowed_profiles' => array('Portal user', ...),
'allow_portal_users_rest_access' => false, // default: false (maintains current behavior)
),
When allow_portal_users_rest_access is true, allow portal users with valid personal tokens to access the REST API with their existing permission restrictions.
Option 2: Automatic based on Token Authentication
Since personal tokens already have built-in security (scopes, permissions, expiration), automatically allow portal users when using token authentication (but continue blocking basic auth):
// In rest.php, check authentication method
$bUsingPersonalToken = /* check if Auth-Token header is present */;
$bAllowPortalUsers = $bUsingPersonalToken;
$iRet = LoginWebPage::DoLogin(false, $bAllowPortalUsers, LoginWebPage::EXIT_RETURN);
Option 3: Technical Implementation (Tested and Working)
If accepted, the minimal code change requires modifying two lines:
File 1: webservices/rest.php line 103:
// Change from:
$iRet = LoginWebPage::DoLogin(false, false, LoginWebPage::EXIT_RETURN);
// To (when config allows or using personal tokens):
$iRet = LoginWebPage::DoLogin(false, true, LoginWebPage::EXIT_RETURN);
File 2: application/loginwebpage.class.inc.php line 1007:
// Change from:
$sRequestedPortalId = $bIsAllowedToPortalUsers ? 'legacy_portal' : 'backoffice';
// To:
$sRequestedPortalId = $bIsAllowedToPortalUsers ? null : 'backoffice';
This allows the Dispatch() method to bypass portal-specific checks (line 1173) when portal users are allowed.
Impact
This affects any organization that wants to:
- Provide API access to portal users for self-service integrations
- Allow portal users to integrate with third-party tools (e.g., Nextcloud, mobile apps, custom dashboards)
- Maintain a single user account with both portal and API access
Testing & Security Verification
I’ve thoroughly tested the proposed solution and verified:
Functionality:
- ✅ Portal users can successfully authenticate with personal tokens
- ✅ REST API operations work correctly (list_operations, core/get, core/update, etc.)
- ✅ Backoffice users continue to work normally
- ✅ Mixed profile users (Portal + backoffice) work correctly
Security (addressing concerns from #1530):
- ✅ Data access is properly restricted: Portal users can only access data within their existing permissions (same as UI)
- ✅ No scope bypass: Users cannot read, modify and delete any object - they’re limited to their authorized scope
- ✅ Profile restrictions work: Users without proper profiles cannot create or use tokens
- ✅ Token scopes enforced: REST/JSON scope is validated
- ✅ Standard permission checks apply: All UserRights:: checks function normally
- ✅ No privilege escalation: Portal users don’t gain additional access through the API
Example security test:
// Portal user "boris" with only access to their own tickets
// Via UI: Can see only their tickets ✅
// Via API: Can see only their tickets ✅ (verified with core/get)
// Attempting to access other users' tickets: Denied ✅
The key security difference from #1530: Personal tokens use the same authorization system as the UI, unlike basic auth which was the concern in 2018.
Use Case
I’m developing a Nextcloud integration that allows Portal users to link their iTop tickets to Nextcloud. Portal users need API access to retrieve their own ticket information, but the current restriction blocks this legitimate use case despite having all proper authentication and authorization configured.
Summary
This is a feature request to reconsider the restriction established in ticket #1530, given that:
- Personal tokens didn’t exist in 2018 when #1530 was closed
- Personal tokens solve the security concerns raised in #1530
- Current documentation suggests this should work but the code prevents it
- Modern use cases require this functionality (self-service integrations)
- No additional security risk - same permissions as UI access
I understand the original security concern was valid, but personal tokens fundamentally address that issue. I’d appreciate the team’s reconsideration of this restriction or guidance on the proper approach.
I’m happy to contribute a patch implementing whichever option the iTop team prefers (configuration parameter, automatic token detection, or other approach) if this feature request is accepted.
Reference
Related ticket: #1530 (2018 - valid concern for basic auth)
Documentation: https://www.itophub.io/wiki/page?id=extensions:authent-token
Hello @lexioj
Thank you for that very interesting -and detailed ! - ticket.
I've created an internal ticket - N°8789.
I'm also linking your GitHub issue : https://github.com/Combodo/combodo-my-account/issues/3
We'll first check if we're functionally interested in that feature, and if we're, well see how we want it from a technical point of view.
I'll keep you updated.
Many thanks for your message.
Just to give you and your team some impressions of what I am currently working on:
Dynamic Widgets for showing iTop details as a Nextcloud Reference Provider https://docs.nextcloud.com/server/stable/developer_manual/digging_deeper/reference.html (in Talk, Deck, Collectives, etc) when pasting a Link:

Unified Search (planned to support CIs related to user):

Smart-Picker (planned to support CIs related to user):

Admin Settings:


User Settings:

Already planned Features:
Notifications from iTop to Nextcloud
Dashboard Widget
Create Ticket from Talk Chat
Other iTop Extension I am working on:
Nextcloud Talk integration to chat with an Agent (similar what combodo-tawk-integration does for tawk.to)
Alex
Last edit: Vincent @ Combodo 2025-10-14
Hello @lexioj, I'm coming back with some (bad) news.
Unfortunately, user portal as restricted to portal scope (that are different from the scope of tokens.
For example, a portal user is allowed to see every class from iTop, but it's portal scopes that will restrict it.
Also, portal wasn't designed to be accessed through rest and make that can lead to big security issues.
Maybe another way to do that would be to make a specific rest service with a application user, that would check what portal user can see ?
Last edit: jf-cbd 2025-10-24
Hi jf,
thanks for taking time looking into this.
I already decided to switch to a dual-token approach where all requests are performed using an privileged Application Token and restrict access/visibility based on person_id and assigned profiles
I am making good progression on my project and hope to finish within next couple weeks
https://github.com/LexioJ/integration_itop
Nevertheless I needed a way to verify a users iTop identity, therefore I have built https://github.com/LexioJ/itop-portal-personal-tokens to enable creating Personal Tokens to prove identity even if they cannot be used directly due to the restrictions outlined here
Keep up the great work
Alex
Hi LexioJ,
"Nevertheless I needed a way to verify a users iTop identity, therefore I have built https://github.com/LexioJ/itop-portal-personal-tokens to enable creating Personal Tokens to prove identity even if they cannot be used directly due to the restrictions outlined here"
Do you mean your users are in nextcloud and do some basic synchronization between the 2 systems? what if you use some sort of SSO between iTop and Nextcloud? we already have such mecanism with Keycloak for instance. before connecting to iTop, you can have previous user/person/profile provisioning via oauth2...
cf https://www.itophub.io/wiki/page?id=extensions:combodo-hybridauth
BR
Olivier
there is no sync - my nexcloud app is using itop api to search things for reference in documents/chats/todos and to render a dashboard widget to provide overview of currently assigned tickets -> https://github.com/LexioJ/integration_itop/tree/feature/ci-browsing?tab=readme-ov-file
Hey @lexioj, thank your for your message and your comprehension. Tbh, I didn't have time to check what you did for now.
I'm not sure to understand what you mean by dual-token approach.
A solution would be, as you proposed at least the first part), to use an application token and check the credentials (it can be done with check_credentials rest service - in case of user being identified with itop) and then with perform a request, for example with some OQL, to get some info (example : the ticket of the portal user).
Hi again,
this is my approach, as users do not necessarly have a password:
Profile-Based Permissions
Portal Users: See only CIs they are related to via the Contact→CI relationship (contacts_list). No organization-based fallback is applied. iTop's built‑in ACL still applies.
Power Users: If the user has any additional profile beyond "Portal user" (e.g. Service Desk Agent, Service Manager…), allow full CMDB search within iTop ACL.
Dual-Token Architecture
Application Token: Used for all iTop API access by the app. Requests are scoped using the authenticated user's identity (person_id) to preserve isolation.
Personal Token (one-time): Provided by the user once to verify identity; we resolve and store the user's person_id in app config and then discard the token.
Token Storage: Only the application token is stored (encrypted). Personal tokens are never persisted.
Scope Isolation: All queries are performed with the application token but filtered by the stored person_id (and profiles) to enforce per-user visibility.
I have now finally brought iTop Integration to the Nextcloud AppStore 🥳 🍾
https://apps.nextcloud.com/apps/integration_itop
Hope this helps Organisation using both to increase productivity and collaboration.
Wish you all a great weekend.
Alex 👋