Re: [protege-user] WebProtégé 6.0.0: SystemA dmin Role Present but Administrator Options Not Displayed

Hi,

Those settings look good to me. Go ahead and proceed with your testing using WebProtege 4.0.2.

If you’d like to test some of the newer updates from the WebProtege 4.x line, another option is to deploy from the current master branch, which will give you WebProtege 5.x.

WebProtege 4.x and 5.x share essentially the same architecture. WebProtege 6.x, on the other hand, is the latest major release and introduces a microservices architecture along with Keycloak for user management. The rest of the core components remain largely the same.

Best,
Josef

On Aug 5, 2026, at 2:01 AM, Dsouza, Nithin <[email protected]> wrote:

Hello Josef,

I wanted to follow up on the email below. Could you please let me know if you had a chance to review it?

I would appreciate any update when convenient.

Thank you.

Regards,
Nithin Dsouza
From: Dsouza, Nithin
Sent: Thursday, July 30, 2026 2:04 AM
To: 'Josef Hardi' <[email protected]<mailto:[email protected]>>
Cc: User support for WebProtege and Protege Desktop <[email protected]<mailto:[email protected]>>; Deshmukh, Sandeep <[email protected]<mailto:[email protected]>>; Fiedler, Hans-Burkhardt <[email protected]<mailto:[email protected]>>; Reddy Sushma, Yarama <[email protected]<mailto:[email protected]>>
Subject: RE: [protege-user] WebProtégé 6.0.0: SystemAdmin Role Present but Administrator Options Not Displayed

Hello Josef,

Thank you for updating the Dockerfile and deployment instructions. I would like to provide a final update on both environments.

WebProtégé 6:

We pulled the latest changes from the “webprotege-deploy” repository and updated the deployment with the latest container images.

The event-history service is now running successfully on our Linux AMD64/x86_64 server, and the previous architecture compatibility error is no longer present.
We have also completed the application setup and verified that the Create New Project option is now available.

WebProtégé 4:

Before receiving your latest response, we had already completed the WebProtégé 4.0.2 setup using a locally created Dockerfile based on the official release artifacts:

webprotege-server-4.0.2.war
webprotege-cli-4.0.2.jar

The WAR is deployed as the Tomcat root application using Tomcat 8 and Java 11. The environment uses a separate MongoDB 4.1 container, with dedicated persistent Docker volumes for MongoDB and the WebProtégé data directory.

I reviewed the new Docker instructions and noted that they are based on the current master branch and build the development version, 5.0.0-SNAPSHOT.
As our objective is to evaluate the officially released WebProtégé 4.0.2 version, we have continued with the locally built image based on the official 4.0.2 WAR and CLI artifacts.

The deployment is running successfully, and users have already started evaluating the application.

Could you please confirm whether it is acceptable to continue with our current WebProtégé 4.0.2 deployment approach? Please also let us know if you foresee any compatibility, data-persistence, upgrade, or future migration concerns with this setup.

For reference, below is a simplified overview of our WebProtégé 4.0.2 Deployment Architecture, followed by the local docker-compose.yml andDockerfile.runtime configurations currently in use.

Deployment Architecture:
<image003.png>


docker-compose.yml

<image005.png>
































Dockerfile.runtime

<image006.png>












Thank you again for your assistance.

Regards,
Nithin Dsouza

From: Josef Hardi <[email protected]<mailto:[email protected]>>
Sent: Wednesday, July 29, 2026 2:36 AM
To: Dsouza, Nithin <[email protected]<mailto:[email protected]>>
Cc: User support for WebProtege and Protege Desktop <[email protected]<mailto:[email protected]>>; Deshmukh, Sandeep <[email protected]<mailto:[email protected]>>; Fiedler, Hans-Burkhardt <[email protected]<mailto:[email protected]>>; Reddy Sushma, Yarama <[email protected]<mailto:[email protected]>>
Subject: Re: [protege-user] WebProtégé 6.0.0: SystemAdmin Role Present but Administrator Options Not Displayed

This mail has been sent from an external source. Do not reply to it, or open any links/attachments unless you are sure of the sender's identity.


Hi Nithin,

I’ve updated the Dockerfile to build a WebProtege 4 image and added deployment instructions to the README. Give it a try and see if you can deploy WebProtégé locally.

https://github.com/protegeproject/webprotege#building-and-deploying-your-own-docker-image<https://urldefense.com/v3/__https://github.com/protegeproject/webprotege*building-and-deploying-your-own-docker-image__;Iw!!G92We9drHetJ8EofZw!YK5cA-80MpCXoHfT45Uowk9Hwyo0-yrkwBdtXCI-Hu61BstnohydtXjvZcaCrdCYB0kv_Poo7qimkaYtZ3GP5JPH466Tic2m$>

I’ve also fixed the history service for WebProtege 6 so it now runs on AMD64/x86_64 machines. Please pull the webprotege-deploy repo for recent updates.

PS. I’ll be away for a while, but feel free to open GitHub issues if you run into any bugs.

Best,
Josef

On Jul 27, 2026, at 4:13 PM, Dsouza, Nithin <[email protected]<mailto:[email protected]>> wrote:

Hello Josef,

One additional clarification regarding the WebProtégé 4 setup described below:

Could you please confirm whether our locally built WebProtégé 4.0.2 image and the associated Docker Compose configuration are appropriate for the PoC, and whether you foresee any compatibility concerns with this approach?

Regards,
Nithin Dsouza

From: Dsouza, Nithin
Sent: Tuesday, July 28, 2026 4:37 AM
To: 'Josef Hardi' <[email protected]<mailto:[email protected]>>
Cc: User support for WebProtege and Protege Desktop <[email protected]<mailto:[email protected]>>; Deshmukh, Sandeep <[email protected]<mailto:[email protected]>>; Fiedler, Hans-Burkhardt <[email protected]<mailto:[email protected]>>; Reddy Sushma, Yarama <[email protected]<mailto:[email protected]>>
Subject: RE: [protege-user] WebProtégé 6.0.0: SystemAdmin Role Present but Administrator Options Not Displayed

Hello Josef,

Thank you for your earlier guidance.

WebProtégé 4:

You mentioned that the existing published WebProtégé 4 Docker image is the last updated image available and is the most straightforward option for a Docker-based deployment.

Could you please confirm the exact Docker repository and tag you were referring to? If available, could you also share the image digest?

We could not identify an official Docker image specifically corresponding to WebProtégé 4.0.2. We found an open GitHub issue reporting that the published Docker Hub image appears to contain WebProtégé 4.0.0, although we understand that this has not been officially confirmed.

As a result, we created a local Tomcat-based Docker image using the official webprotege-server-4.0.2.war and deployed it as ROOT.war. The application is exposed externally on port 8081.

As part of our local Docker Compose configuration, we also:

  *   Added a separate MongoDB container using mongo:4.1-bionic.
  *   Configured WebProtégé to connect to MongoDB using the Compose service name wpmongo.
  *   Mapped MongoDB’s /data/db directory to a persistent Docker named volume.
  *   Mapped WebProtégé’s /srv/webprotege directory to a separate persistent Docker named volume.

After the initial deployment and login, WebProtégé displayed the following warning:

WebProtégé is not configured properly

We completed the required settings through the WebProtégé Application Settings page, including the application hostname, scheme, external port, notification setting, project creation, and project upload options.

After applying these settings, the warning disappeared, the Create New Project option became available, and the settings persisted after restarting the container.

WebProtégé 6:

While deploying WebProtégé 6 on our AMD64/x86_64 server, we found that the event-history service image referenced by the deployment is built for ARM64. As a result, the service cannot run natively on our server.

Could you please confirm whether an AMD64-compatible or multi-architecture image for the event-history service is planned for a future release?

Thank you for your support.

Regards,
Nithin Dsouza

From: Josef Hardi <[email protected]<mailto:[email protected]>>
Sent: Saturday, July 25, 2026 9:50 AM
To: Dsouza, Nithin <[email protected]<mailto:[email protected]>>
Cc: User support for WebProtege and Protege Desktop <[email protected]<mailto:[email protected]>>; Deshmukh, Sandeep <[email protected]<mailto:[email protected]>>; Fiedler, Hans-Burkhardt <[email protected]<mailto:[email protected]>>; Reddy Sushma, Yarama <[email protected]<mailto:[email protected]>>
Subject: Re: [protege-user] WebProtégé 6.0.0: SystemAdmin Role Present but Administrator Options Not Displayed

This mail has been sent from an external source. Do not reply to it, or open any links/attachments unless you are sure of the sender's identity.


Hi Nithin,

Thank you for your questions and I’m sorry for the silence. Please see my responses below.

1. For the missing Create New Project button in WebProtégé 6.0, please update your webprotege-deploy repository and use the latest docker-compose file.

2. We do not currently have an estimated timeline for the official WebProtégé 6.0.0 release. There is no dedicated grant supporting long-term WebProtégé development, and my current contributions are temporary while I’m between projects. As a result, I’m unable to provide a reliable release timeline.

3. I cannot give a definitive recommendation for a production deployment. The master branch contains changes made after the 4.0.2 release, but the existing Docker Hub image does not appear to be built from the latest master. Therefore, using master would require you to build the Docker image locally from the source. For the most straightforward Docker-based deployment, you can use the existing published image, but please be aware that it is old.

4. For a Docker-based WebProtégé 4 deployment, the Running from Docker section in the repository should provide straightforward instructions:

https://github.com/protegeproject/webprotege#running-from-docker<https://urldefense.com/v3/__https:/github.com/protegeproject/webprotege*running-from-docker__;Iw!!G92We9drHetJ8EofZw!a7PYjTuiGUtzGKBFmkd8M7ua7zOOwm7g1_h2k_8BpD_yESgXzkpPo_g5XrncKySEMmXjuGKNlurAzFBrTj9E-birfLyS9zyS$>

5. I have developed a user migration tool that migrates WebProtégé 4 users from MongoDB to the Keycloak instance used by WebProtégé 6.0:

https://github.com/protegeproject/webprotege-user-migration-tool<https://urldefense.com/v3/__https:/github.com/protegeproject/webprotege-user-migration-tool__;!!G92We9drHetJ8EofZw!a7PYjTuiGUtzGKBFmkd8M7ua7zOOwm7g1_h2k_8BpD_yESgXzkpPo_g5XrncKySEMmXjuGKNlurAzFBrTj9E-birfPWuS_bK$>

However, I haven’t fully tested the tool so the migration process should not yet be considered officially supported.

6. The migration process is intended to preserve the existing projects, revision history, user information, project ownership, sharing permissions, and related settings automatically. These should not need to be recreated manually.

7. Users will need to reactivate their accounts in WebProtégé 6.0 by setting a new password. WebProtégé 4 stores passwords as MD5 hashes, and these passwords cannot be migrated into Keycloak.

8. During migration, the user’s email address is used as the Keycloak username and login identifier. The original WebProtégé username is stored as a special Keycloak attribute so that existing project ownership and sharing permissions can be preserved.

Regarding HTTPS support for WebProtégé 4.0.2, I am afraid I do not know the recommended reverse-proxy configuration off the top of my head. I will ask the team and share the recommended approach when I have more information.

Finally, WebProtégé 4 has been unmaintained for quite some time, while WebProtégé 6 development has also had limited and less sustainable resources. The existing WebProtégé 4 Docker image is the last updated image available for that version. Therefore, it is the most straightforward option for a WebProtégé 4 deployment, but please be aware that it is based on an older and no longer actively maintained release.

Given these limitations, continuing your PoC with the latest WebProtégé 6 development deployment may give you a better view of the future platform. However, it should not yet be treated as production-ready. WebProtégé 4 is more stable in its current state, although it is no longer actively maintained. It is also the same major version that powers our official WebProtégé<https://webprotege.stanford.edu/> service at Stanford and continues to serve our users reliably, so it remains a reasonable choice for a stable deployment.

Best,
Josef

On Jul 24, 2026, at 12:00 PM, Dsouza, Nithin <[email protected]<mailto:[email protected]>> wrote:

Hello Josef,

Did you get a chance to have a look at the emails below.

Regards,
Nithin Dsouza

From: Dsouza, Nithin
Sent: Thursday, July 23, 2026 3:11 AM
To: 'Josef Hardi' <[email protected]<mailto:[email protected]>>; 'User support for WebProtege and Protege Desktop' <[email protected]<mailto:[email protected]>>
Cc: Deshmukh, Sandeep <[email protected]<mailto:[email protected]>>; Fiedler, Hans-Burkhardt <[email protected]<mailto:[email protected]>>; Reddy Sushma, Yarama <[email protected]<mailto:[email protected]>>
Subject: RE: [protege-user] WebProtégé 6.0.0: SystemAdmin Role Present but Administrator Options Not Displayed

Hello Josef,

I have two additional queries regarding WebProtégé 4.0.2:


  1.  Could you please confirm whether WebProtégé 4.0.2 can be deployed for multi-user access over both HTTP and HTTPS? If HTTPS is supported through a reverse proxy, could you please share the recommended configuration or documentation?
  2.  Could you please confirm the recommended deployment method for a stable, self-hosted WebProtégé 4.0.2 installation? We noticed that the available Docker image may not correspond to the 4.0.2 release, as mentioned in GitHub Issue #815. Kindly advise whether we should use the existing Docker image or deploy the official 4.0.2 WAR artifact, or whether you recommend another supported approach.

Regards,
Nithin Dsouza

From: Dsouza, Nithin
Sent: Thursday, July 23, 2026 2:32 AM
To: Josef Hardi <[email protected]<mailto:[email protected]>>; User support for WebProtege and Protege Desktop <[email protected]<mailto:[email protected]>>
Cc: Deshmukh, Sandeep <[email protected]<mailto:[email protected]>>; Fiedler, Hans-Burkhardt <[email protected]<mailto:[email protected]>>; Reddy Sushma, Yarama <[email protected]<mailto:[email protected]>>
Subject: RE: [protege-user] WebProtégé 6.0.0: SystemAdmin Role Present but Administrator Options Not Displayed

Hello Josef,

Thank you for the clarification and recommendation.

Before we decide whether to continue testing WebProtégé 6.0.0 or deploy the current stable WebProtégé 4.0.2 release, could you please clarify the following:

1. You mentioned that the latest “webprotege-deploy” should resolve the missing Create New Project button. Could you please confirm whether updating the deployment repository and pulling the latest container images is sufficient, or whether any additional configuration changes are required?

2. Is there an estimated timeline for the official release of WebProtégé 6.0.0?

3. For a stable self-hosted WebProtégé 4 installation, do you recommend using the latest “master” branch of the “protegeproject/webprotege” repository or the official WebProtégé “4.0.2 release tag” and artifacts?

4. Could you please share the currently recommended installation documentation for a new self-hosted WebProtégé 4.0.2 deployment?

As I am still in the initial phase of exploring WebProtégé, I am also curious about the longer-term migration approach. If we proceed with WebProtégé 4.0.2 now and later move to WebProtégé 6.0.0:

5. Will there be an officially supported migration path or migration tool?

6. Would the migration preserve ontology projects, revision history, user accounts, project ownership, permissions, and application settings, or might any of these need to be recreated manually?

7. Since WebProtégé 6.0.0 uses Keycloak for authentication, would migrated users need to create or reset their passwords?

8. How will existing WebProtégé 4.0.2 usernames and email addresses be mapped to Keycloak? Will the migration preserve the original usernames and their links to project ownership and permissions, or will email addresses become the login usernames?

These migration-related questions are mainly for our preliminary understanding and future planning. Our immediate objective is to determine whether we should continue the PoC using the latest WebProtégé 6.0.0 development deployment or proceed with the stable WebProtégé 4.0.2 release.

Thank you for your guidance.

Regards,
Nithin Dsouza

From: Josef Hardi <[email protected]<mailto:[email protected]>>
Sent: Wednesday, July 22, 2026 2:04 AM
To: User support for WebProtege and Protege Desktop <[email protected]<mailto:[email protected]>>
Cc: Dsouza, Nithin <[email protected]<mailto:[email protected]>>; Deshmukh, Sandeep <[email protected]<mailto:[email protected]>>; Fiedler, Hans-Burkhardt <[email protected]<mailto:[email protected]>>; Reddy Sushma, Yarama <[email protected]<mailto:[email protected]>>
Subject: Re: [protege-user] WebProtégé 6.0.0: SystemAdmin Role Present but Administrator Options Not Displayed

This mail has been sent from an external source. Do not reply to it, or open any links/attachments unless you are sure of the sender's identity.


Hi Nithin,

WebProtege 6.0.0 has not been officially released yet and is not ready for production use. For now, I’d recommend using WebProtege 4.0, which is the current stable release.

https://github.com/protegeproject/webprotege<https://urldefense.com/v3/__https:/github.com/protegeproject/webprotege__;!!G92We9drHetJ8EofZw!Z-DJ39WnuhPJObUAOOACce5CrmTSqCwSfNF9HX8Lasvwcfk8wXXCrGTda9nsP3B8dd6xDe05stJ-ZkXUjW4aJyKoFbgPazDy$>

That said, you’re welcome to be one of the first to test it if you’re interested. The latest webprotege-deploy should fix the missing “Create New Project” button.

Best,
Josef

On Jul 21, 2026, at 11:49 AM, Dsouza, Nithin via protege-user <[email protected]<mailto:[email protected]>> wrote:

Hello WebProtégé Support Team,

I am testing a fresh, self-hosted WebProtégé 6.0.0 deployment using the protegeproject/webprotege-deploy Docker Compose repository.

The user can register and sign in successfully. However, after signing in, the home page displays only an empty project list. The Create Project, Upload Project, and Application Settings options are not available.

Environment


  *   Operating system: RHEL 9
  *   Deployment method: Docker Compose
  *   Architecture: WebProtégé microservices
  *   Deployment branch: main
  *   Deployment commit: e3ad731
  *   WebProtégé UI: 6.0.0
  *   GWT UI server: 9.0.20
  *   Backend service: 5.0.10
  *   Authorization service: 3.0.9
  *   Keycloak integration: 2.0.1
  *   MongoDB: 8.0.10


User and Login Details

The test account was registered using [email protected]<mailto:[email protected]>, as the registration form requires an email-format identifier. The email address shown here has been anonymized for this public support request.

[email protected]<mailto:[email protected]>

The SystemAdmin client role has been assigned to this account under the webprotege client in Keycloak.

Validation completed

I have confirmed the following:

  *   All required WebProtégé containers are running.
  *   The WebProtégé login and home pages are accessible.
  *   Keycloak authentication and user login are working.
  *   The SystemAdmin client role is assigned to the test account.
  *   The generated Keycloak access token contains:



"resource_access": {
  "webprotege": {
    "roles": [
      "SystemAdmin"
    ]
  }
}

The generated token contains:

"preferred_username": "[email protected]<mailto:[email protected]>"


  *   The backend and authorization services recognize the account and successfully process requests.
  *   MongoDB and RabbitMQ connectivity are working.
  *   Nginx is serving the UI, and no failed requests or error status codes were observed in the browser Network tab.
  *   No relevant recent errors or exceptions are present in the backend or authorization-service logs.
  *   The behavior was reproduced using a fresh private browser session, ruling out browser caching.
  *   This is a fresh installation, so no application upgrade or database migration was involved.


The authorization logs show successful requests such as:

Received command webprotege.authorization.GetAuthorizedCapabilities
Request executed webprotege.authorization.GetAuthorizedCapabilities

Received command webprotege.authorization.GetAuthorizedResources
Request executed webprotege.authorization.GetAuthorizedResources

The backend logs also show successful requests such as:

Received command webprotege.users.GetAuthenticatedUserDetails
Request executed webprotege.users.GetAuthenticatedUserDetails

Received command webprotege.projects.GetAvailableProjects
Request executed webprotege.projects.GetAvailableProjects


Authorization observations
The MongoDB RoleAssignments collection remains empty:

db.RoleAssignments.countDocuments()

Result:
0

I also reviewed:


  *   webprotege-authorization-service Issue #36
  *   webprotege-deploy Issue #62


The proposed INITIAL_ADMIN_USERNAME bootstrap does not appear to be implemented in authorization-service 3.0.9 or wired into the current deployment.

For testing, the following temporary minimal RoleAssignments document was inserted using the same anonymized email-format username recognized by the backend and authorization-service logs:

db.RoleAssignments.insertOne({
  userName: "[email protected]<mailto:[email protected]>",
  projectId: null,
  assignedRoles: ["SystemAdmin"]
})

However, this resulted in a RoleAssignment deserialization error because the required roleClosure and capabilityClosure fields were missing:

Cannot construct instance of
edu.stanford.protege.webprotege.authorization.RoleAssignment

java.lang.NullPointerException

The temporary document was subsequently removed, and the RoleAssignments collection is empty again.

Questions

Could you please advise on the following?


  1.  Is assigning the SystemAdmin client role under the webprotege client in Keycloak sufficient for this deployment version?
  2.  Is a MongoDB RoleAssignments document required in addition to assigning the SystemAdmin role in Keycloak? If so, could you please provide the complete and supported MongoDB query for creating the initial administrator assignment, including the required roleClosure and capabilityClosure fields?



  1.  What is the supported procedure for granting full administrative access to the first registered user?
  2.  Is there a compatible authorization-service version that implements the proposed initial-administrator bootstrap?
  3.  Are any additional client scopes, token mappers, or WebProtégé application settings required?
  4.  Is an email-format value such as [email protected]<mailto:[email protected]> supported as the preferred_username and WebProtégé authorization username?
  5.  If a separate, non-email webprotege_username value is required, how should it be created and mapped for users registered through the email-only registration form?


Thank you for your assistance.

_________________________________________________________________
Thanks & Regards,
Nithin Dsouza
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. _______________________________________________
protege-user mailing list
[email protected]<mailto:[email protected]>
https://mailman.stanford.edu/mailman/listinfo/protege-user

_______________________________________________
protege-user mailing list
[email protected]
https://mailman.stanford.edu/mailman/listinfo/protege-user