Crowd 6.0 EAP is out

We’ve just released an Early Access Program (EAP) of Crowd 6.0 so you can get familiar with the upcoming changes. Unless we need to include emergency or unplanned changes, this should be the only EAP for Crowd 6.0.

Highlights

  • Migration to Java 17: We’ve removed support for JDK 8 and 11. Crowd 6.0 only supports JDK 17.
  • Removed support for JNDI datasource connection: We’ve removed JNDI as a method for connecting to the database.
  • Upgrade to Platform 7: We’ve upgraded to Atlassian Data Center Platform 7.
  • Endpoint default security annotations: By default, endpoints will require an authenticated user instead of allowing public access.
  • Front-end dependencies SBOM file included in the distribution: With this improvement Crowd becomes compliant with the Secure Software Development Framework.

Downloads and documentation

For details, check out the documentation on how to prepare for Crowd 6.0.

Share your feedback

If there’s anything we can provide that will make it easier for you to understand and plan for the changes, let us know by commenting below this post.

Happy testing,
The Crowd team

Hi @MichalSamujlo

I encountered the following warning in the logs while attempting to install our plugin:

“Package com.atlassian.crowd.manager.authentication is internal and is not available for export.”

Our apps requires access to this package. Could you please consider exporting this package or suggest an alternative solution?

Your assistance would be greatly appreciated.

Thanks,
Lokesh

Hi,

we are maintaining a custom internal plugin for Crowd. When preparing for Crowd 6.0, we are seeing this error

Package com.atlassian.config.util is internal and is not available for export to plugin

Then, the startup of our plugin fails.

The same error is reported by the community for Confluence: Preparing for Confluence 9.0 - EAP out now - #476 by fgrund
A member of the atlassian team responded and said this will be fixed soon for Confluence.

Is this error already known for Crowd as well? Is there maybe already a timeline for the fix?

Thanks,
Jonas

Hi @MichalSamujlo,

I hope you’re doing well. We’re facing an issue with the error is internal and is not available for export. If possible, could we kindly request the same level of support the Atlassian team provided when we were working on making the app compatible with Confluence and Jira?

Thanks,
Lokesh

Thank you for your patience, and I apologize for the delay in responding.

For security reasons, we intentionally restricted access to selected packages in Crowd 6.0. However, it appears that restricting access to com.atlassian.config.util was unintended. I understand the impact this may have on your work, and I’m sorry for any inconvenience caused. We plan to include a fix in the upcoming bug fix release scheduled for the next week.

@lokesh It’s more complex for com.atlassian.crowd.manager.authentication package which was blocked for security reasons. Can you please tell us which classes from this package you use and how? We will try to find a solution.

Hi @MichalSamujlo,

Thanks for the response.

We have the SSO and MFA app for Crowd where we need to authenticate users to create a session. To achieve this, we’re utilizing com.atlassian.crowd.manager.authentication.TokenAuthenticationManager to authenticate the user and generate a session token. We have also tried com.atlassian.crowd.integration.http.CrowdHttpAuthenticator but stuck with the same issue.

Thanks,
Lokesh

@lokesh We decided to expose com.atlassian.crowd.manager.authentication and also mark it as deprecated. The change will be available in the next patch version (6.0.4) and in 6.1+ .

We would like to remove access to this package in Crowd 7.0 and introduce new public API.

Hi @MichalSamujlo,

Thank you for the update, we really appreciate your assistance.

I wanted to check if there is an estimated release date for Crowd v6.0.4. Having this information would allow us to provide more accurate communication to our customers who are eagerly awaiting updates for our apps.

Thanks again for your support!

Thanks,
Lokesh

Fixed

Excuse me for late response.

The fix was released with Crowd 6.1.0 on September 27 and 6.0.3 on October 8.

we are implementing a Servlet in an Add-On. Unfortunately I get

missing requirement [XXX [53](R 53.0)] osgi.wiring.package; (&(osgi.wiring.package=com.atlassian.crowd.console.action)(version>=6.1.0)(version<=6.1.0)) Unresolved requirements: [[XXX [53](R 53.0)] osgi.wiring.package; (&(osgi.wiring.package=com.atlassian.crowd.console.action)(version>=6.1.0)(version<=6.1.0))]

Why am I not able to get the ActionHelper? It is very useful to get information like the logged in User.

Same for
com.atlassian.crowd.service.client.CrowdClient which was announced to be available again in 6.1.0

@MarioAnstoots Several Java packages were removed in version 6.0 for security reasons, including com.atlassian.crowd.console.action and com.atlassian.crowd.service.client. These packages are not planned to be reintroduced in version 6.1.

Here are some recommendations for migrating to version 6.0:

  • com.atlassian.crowd.console.action
    The following service and method can be used to retrieve information about the current user: com.atlassian.sal.api.user.UserManager#getRemoteUser().
  • com.atlassian.crowd.service.client
    com.atlassian.crowd.service.client.CrowdClient is no longer exported via OSGi, but it can still be used as a Maven dependency. It is available in Atlassian’s public Maven repository. It is also possible to use other general-purpose REST clients to access the Crowd REST API.

Hi thank you for the hint for the ActionHelper.

Which dependency is needed for com.atlassian.crowd.service.client.CrowdClient?

And we use a servlet filter that should filter every (literally every) request, as it checks the authentication. It works for all requests after the login, but not for the original login itself (http://localhost:8095/crowd/console/login.action) or the base-url (http://localhost:8095/crowd)

It worked before with older versions of crowd.

<servlet-filter name="xxx"
		key="xxx"
		class="xxx"
	location="before-login" >
		<description>xxx</description>
		<url-pattern>*</url-pattern>
		<dispatcher>REQUEST</dispatcher>
		<dispatcher>FORWARD</dispatcher>
	</servlet-filter>

@MarioAnstoots To create an instance of CrowdClient, you need to include the following two libraries in your project:

  1. com.atlassian.crowd:crowd-integration-client-common
  2. com.atlassian.crowd:crowd-integration-client-rest

Below is a sample pseudo-code demonstrating how to instantiate a CrowdClient:

import com.atlassian.crowd.integration.rest.service.factory.RestCrowdClientFactory;
import com.atlassian.crowd.service.client.CrowdClient;

....
        // Create a new instance of CrowdClient using the factory
        RestCrowdClientFactory factory = new RestCrowdClientFactory();
        CrowdClient crowdClient = factory.newInstance(
            "<crowd-url>",        // replace <crowd-url> with the actual URL to Crowd, e.g. https://crowd-inst:8080/crowd,
            "<app-name>",         // replace <app-name> with the actual application name
            "<app-passwd>"        // replace <app-passwd> with the actual application password
);

Thank you, that is enough for now.

How about the servlet filter not working before the login?

And we use a servlet filter that should filter every (literally every) request, as it checks the authentication. It works for all requests after the login, but not for the original login itself (http://localhost:8095/crowd/console/login.action) or the base-url (http://localhost:8095/crowd)

It worked before with older versions of crowd.

<servlet-filter name="xxx"
		key="xxx"
		class="xxx"
	location="before-login" >
		<description>xxx</description>
		<url-pattern>*</url-pattern>
		<dispatcher>REQUEST</dispatcher>
		<dispatcher>FORWARD</dispatcher>
	</servlet-filter>

@MarioAnstoots

And we use a servlet filter that should filter every (literally every) request, as it checks the authentication. It works for all requests after the login, but not for the original login itself

This probably happens due to a missing security annotation on the servlet filter class. For filters where the location option is set to before-login, you may need to use @UnrestrictedAccess. This document offers information on the topic: Prepare your Data Center app to comply with secure endpoint defaults.

Hi there, thank you again for this. This filter redirects to our servlet at /plugins/servlet/xyz but this gives AccessDenied.
The Servlet already uses @UnrestrictedAccess on doGet and doPost, but it still gives AccessDenied Page and no call on the servlet at all. Any idea on this?

@MarioAnstoots

The Servlet already uses @UnrestrictedAccess on doGet and doPost, but it still gives AccessDenied Page and no call on the servlet at all.

This issue may occur if the servlet method, such as doGet , is not declared as public. Annotations on non-public methods are ignored.

I added @UnrestrictedAccess before the Servlet Class declaration and now it works.

Last thing missing, i hope, is the
com.atlassian.crowd.manager.login.ForgottenLoginManager;

Is it possible to get it? Or to create a forgotten login mail and the corresponding process any other way?

@MarioAnstoots The package com.atlassian.crowd.manager.login, which includes the ForgottenLoginManager class, will be made available for OSGi import starting with version 6.0 in the next patch - v6.0.5.