Source code in ForgeRock products

This book provides information on source code and binaries in ForgeRock products (AM/OpenAM, DS/OpenDJ, IDM/OpenIDM and IG/OpenIG).


Source Code


Building from Source


How do I build OpenAM 12.x and 13.x from source?

The purpose of this article is to provide guidance on building OpenAM Enterprise and Maintenance releases from source. This method uses ForgeRock password protected Apache Maven™ repositories, which include the required artifacts. Artifacts for releases are only available when using these repositories; release builds will fail without these artifacts.

Warning

ForgeRock support covers the use of the official binary builds made available and downloaded from our customer portal: BackStage. We will support builds made from source providing no changes have been made to the core code of the product, the product was built from a tag that matches an official release, for example, 13 and said product was built using the ForgeRock build scripts provided as part of the source. In the event that a customer experiences an issue with a ForgeRock product built from source where ForgeRock believe the issue is as a result of the build process, ForgeRock reserves the right to ask the customer to attempt to reproduce the issue on an official ForgeRock binary build. Customers who are running custom builds or who need further clarification should contact their ForgeRock sales representative.

Overview

The OpenAM source code is available in Git repositories hosted on our Bitbucket® Server.

You should follow this process to build OpenAM successfully:

  1. Generate a ~/.m2/settings.xml file per How do I access the ForgeRock protected Maven repositories? It is essential that you create a valid settings.xml to access the Maven repositories needed for the build process. Failing to do this will cause your build to fail.
  2. Install the correct versions of Oracle® JDK and Apache Maven™ as detailed in the Dependencies section.
  3. Create a SSH key and add it to your Bitbucket profile to allow you to clone the source code with a SSH URL.
  4. Set up the OpenDMK library as detailed in How do I set up the OpenDMK library for building AM/OpenAM (All versions) and DS/OpenDJ (All versions) from source?
  5. Build OpenAM using the steps in one of the following sections only depending on what you are trying to build:
  6. Read the Troubleshooting section if you encounter any issues as this covers the common issues that can cause a build to fail.

* The SecurID authentication module is missing in OpenAM 13.0; you can either follow the steps in this article to include it when you build from source or can apply a patch to your WAR file as detailed in SecurID authentication module is missing from OpenAM 13.0.

Note

You may notice that one of the artifacts is downloaded from an Oracle® repository (http://download.oracle.com/maven); this is the database engine (Berkeley DB Java Edition) which does come from the Oracle library. As of AM 5 / DS 5, we use a new JE version (7.3), which is Apache V2 and Open Source; this newer version is hosted in the ForgeRock repository.

Dependencies

You should use Git 1.7.6 or above, and build with the appropriate version of Oracle JDK and Maven depending on your version of OpenAM:

Version Oracle JDK version Maven version
OpenAM 13.5.x 1.7 * 3.3.0 or later
OpenAM 13.0.0 1.7 or 1.8 3.1.0 or later
OpenAM 12.x

1.7 or 1.8

1.6

3.1.0 or later

3.3.1 or earlier

OpenAM 11.0.3

1.7

1.6

3.1.0 or later

3.3.1 or earlier

* There is a known issue with building OpenAM 13.5.x with JDK 1.8: OPENAM-10314 (OpenAM Maven Javadocs does not work with Java 8.).

Enterprise release

You can build an Enterprise release from source as follows:

  1. Git clone the OpenAM enterprise releases repository:
    $ git clone ssh://git@stash.forgerock.org:7999/openam/openam-public.git
  2. Find the required tag in the repository you just cloned; the git tag command lists all the tags in a repository:
    $ cd openam-public
    $ git tag
    
    10.1.0-Xpress
    11.0.0
    12.0.0
    12.0.0-1
    13.0.0
    
  3. Check out the required tag. For example, 13.0.0:
    $ git checkout 13.0.0
  4. Set your Maven options:
    $ export MAVEN_OPTS=-Xmx512m
    
  5. Build OpenAM using the following command:
    $ mvn clean install
    If all is successful, you'll find that everything has been built in ./openam-server/target.

Maintenance release

You can build a Maintenance release from source as follows:

  1. Git clone the OpenAM maintenance releases repository:
    $ git clone ssh://git@stash.forgerock.org:7999/openam/openam-sustaining-external.git
  2. Find the required tag in the repository you just cloned; the git tag command lists all the tags in a repository:
    $ cd openam-sustaining-external
    $ git tag
    
    10.1.0-Xpress
    10.1.0-Xpress-docs
    11.0.0
    12.0.0
    12.0.0-1
    12.0.0-2
    12.0.0-3
    13.0.0
    13.5.0
    ....
    
  3. Check out the required tag. For example, 13.5.0:
    $ git checkout 13.5.0
  4. Set your Maven options:
    $ export MAVEN_OPTS=-Xmx512m
    
  5. If you are building a pre-OpenAM 13.5 maintenance release, you may need to update the pom.xml file in the checked out source to look for the ForgeRock private repository by adding the following to the <repositories> section if it does not exist:
    <repository>
         <id>forgerock-private-releases</id>
         <name>maven.forgerock.org-releases</name>
         <url>http://maven.forgerock.org/repo/private-releases</url>
         <snapshots>
              <enabled>false</enabled>
         </snapshots>
    </repository>
    
    
    This section already exists for OpenAM 13.5.x.
  6. If you are building OpenAM 12.0.2, you need to perform the following additional steps prior to building:
    1. Update the pom.xml file in the checked out source to correct the forgerock-ui.version. This shows as follows:
      <forgerock-ui.version>1.1.10-2-SNAPSHOT</forgerock-ui.version>
      
      And should be changed to:
      <forgerock-ui.version>1.1.10-2</forgerock-ui.version>
      
    2. Create a new src/main/resources/console directory in the openam-server-only directory: 
      $ cd openam-server-only
      $ mkdir src/main/resources/console
  7. Build OpenAM using the following command:
    $ mvn clean install
    If all is successful, you'll find that everything has been built in ./openam-server/target.

Enterprise release with SecurID authentication module

You can build an Enterprise release with the SecurID authentication module from source as follows:

  1. Request the latest authapi jar file from RSA®.
  2. Install the authapi jar file using the following command (replacing 2005-08-12 with the version of the jar file provided by RSA):
    $ mvn install:install-file -Dfile=./authapi-2005-08-12.jar -DgroupId=external -DartifactId=authapi -Dversion=2005-08-12 -Dpackaging=jar
    
  3. Git clone the OpenAM enterprise releases repository:
    $ git clone ssh://git@stash.forgerock.org:7999/openam/openam-public.git
  4. Find the required tag in the repository you just cloned; the git tag command lists all the tags in a repository:
    $ cd openam-public
    $ git tag
    
    10.1.0-Xpress
    11.0.0
    12.0.0
    12.0.0-1
    13.0.0
    
  5. Check out the required tag. For example, 13.0.0:
    $ git checkout 13.0.0
  6. Set your Maven options:
    $ export MAVEN_OPTS=-Xmx512m
    
  7. If you are building OpenAM 13.0, update the openam-authentication/openam-auth-securid/pom.xml file in the checked out source to correct the OpenAM version. This shows as follows:
    <version>13.0.0-SNAPSHOT</version>
    
    And should be changed to:
    <version>13.0.0</version>
    
  8. Build OpenAM using the following command:
    $ mvn clean install -Prelease
    If all is successful, you'll find that everything has been built in ./openam-server/target.
  9. If you are building OpenAM 13.0, run the following ssoadm command to update the service schema with the SecurID authentication module:
    $ ./ssoadm update-svc [adminID] -f [passwordfile] -X amAuthSecurID.xml
    replacing [adminID] and [passwordfile] with appropriate values.

Maintenance release with SecurID authentication module

You can build a Maintenance release with the SecurID authentication module from source as follows:

  1. Request the latest authapi jar file from RSA.
  2. Install the authapi jar file using the following command (replacing 2005-08-12 with the version of the jar file provided by RSA):
    $ mvn install:install-file -Dfile=./authapi-2005-08-12.jar -DgroupId=external -DartifactId=authapi -Dversion=2005-08-12 -Dpackaging=jar
    
  3. Git clone the OpenAM maintenance releases repository:
    $ git clone ssh://git@stash.forgerock.org:7999/openam/openam-sustaining-external.git
  4. Find the required tag in the repository you just cloned; the git tag command lists all the tags in a repository:
    $ cd openam-sustaining-external
    $ git tag     
           
    10.1.0-Xpress
    10.1.0-Xpress-docs
    11.0.0
    12.0.0
    12.0.0-1
    12.0.0-2
    12.0.0-3
    13.0.0
    13.5.0
    ....
    
  5. Check out the required tag. For example, 13.5.0:
    $ git checkout 13.5.0
  6. Set your Maven options:
    $ export MAVEN_OPTS=-Xmx512m
    
  7. If you are building a pre-OpenAM 13.5 maintenance release, you may need to update the pom.xml file in the checked out source to look for the ForgeRock private repository by adding the following to the <repositories> section if it does not exist:
    <repository>
         <id>forgerock-private-releases</id>
         <name>maven.forgerock.org-releases</name>
         <url>http://maven.forgerock.org/repo/private-releases</url>
         <snapshots>
              <enabled>false</enabled>
         </snapshots>
    </repository>
    
    
    This section already exists for OpenAM 13.5.x.
  8. If you are building OpenAM 12.0.2, you need to perform the following additional steps prior to building:
    1. Update the pom.xml file in the checked out source to correct the forgerock-ui.version. This shows as follows:
      <forgerock-ui.version>1.1.10-2-SNAPSHOT</forgerock-ui.version>
      
      And should be changed to:
      <forgerock-ui.version>1.1.10-2</forgerock-ui.version>
      
    2. Create a new src/main/resources/console directory in the openam-server-only directory: 
      $ cd openam-server-only
      $ mkdir src/main/resources/console
  9. Build OpenAM using the following command:
    $ mvn clean install -Prelease
    If all is successful, you'll find that everything has been built in ./openam-server/target.

Troubleshooting

If your build fails, you should check the following:

See Also

FAQ: Source code in AM/OpenAM

How do I access the ForgeRock protected Maven repositories?

SecurID authentication module is missing from OpenAM 13.0

FAQ: SecurID authentication module in AM/OpenAM

Source code in ForgeRock products

Maven Settings Reference

Related Training

N/A

Related Issue Tracker IDs

OPENAM-10317 (OpenAM 13.5.x openam-ui-ria does not build on Windows and Linux)

OPENAM-10316 (Remove error from Maven build on openam-ui-ria for Windows)

OPENAM-10314 (OpenAM Maven Javadocs does not work with Java 8.)

OPENAM-9707 (compilation of 13.5.0 fails on windows during tests: FileSystemNotFoundException setup%5cinstalled-opendj-base-directory.zip)

OPENAM-9526 (Compiling the source code without git repo fails at openam-clientsdk module)

OPENAM-8456 (SecurID authentication module is missing from 13.0.0)


How do I update and recompile the iOS authenticator app with custom branding in AM (All versions)?

The purpose of this article is to provide information on updating and recompiling the iOS® authenticator app in AM so that it can be published to the Apple® App Store. Changes include renaming the app and rebranding changes, such as updating the Splashscreen video, updating the app icon and changing default colours.

Warning

ForgeRock support covers the use of the official binary builds made available and downloaded from our customer portal: BackStage. We will support builds made from source providing no changes have been made to the core code of the product, the product was built from a tag that matches an official release, for example, 6 and said product was built using the ForgeRock build scripts provided as part of the source. In the event that a customer experiences an issue with a ForgeRock product built from source where ForgeRock believe the issue is as a result of the build process, ForgeRock reserves the right to ask the customer to attempt to reproduce the issue on an official ForgeRock binary build. Customers who are running custom builds or who need further clarification should contact their ForgeRock sales representative.

Overview

This article explains how to clone the iOS ForgeRock Authenticator app source code and create your own version of the app that you can publish to the Apple App Store. There is also a section that provides links relevant to setting up Push notifications.

High level steps

  1. Create a new iOS App Bundle ID
  2. Obtain Authenticator source, prepare a project and open in Xcode
  3. Launch the App on an iPhone®
  4. Rename the project
  5. Rename the scheme
  6. Update the CocoaPods configuration
  7. Rename the ForgeRock-Authenticator directory
  8. Rename the Entitlements file
  9. Update the Build settings and rebuild
  10. Update the Test Build settings
  11. Update the Splashscreen video
  12. Update App Permission Request dialogs
  13. Update Localizable.strings
  14. Update About.strings
  15. Update the App icon
  16. Update the Default Account icon
  17. Update the Default colors
  18. Publish your App

These steps were completed using Xcode Version 10.0 (10A255).

Note

Before updating the Authenticator app, please make sure Xcode® is installed and up-to-date.

Create a new iOS App Bundle ID

  1. Log in to your paid Apple Developer account (http://developer.apple.com/account).
  2. Select Certificates, Identifiers & Profiles.
  3. Select App IDs (under Identifiers in the menu on the left).
  4. Select the “+” (Add) icon.
  5. Complete the Registering an App ID form:
    1. Enter an App ID description, for example “ACME Authenticator”.
    2. Select Explicit App ID and enter a bundle ID, for example “com.acme.authenticator”.
    3. Leave default selections for App Services (we will enable “Push Notifications” later in this article):

  1. Select “Register”, then “Done” to complete creation of your new iOS App Bundle ID. 

Obtain Authenticator source, prepare a project and open in Xcode

Note

To clone the source code with a SSH URL, you must have created a SSH key and added it to your Bitbucket profile.

  1. Git clone the ForgeRock Authenticator iOS repository:
    $ git clone ssh://git@stash.forgerock.org:7999/openam/forgerock-authenticator-ios.git
  2. Install CocoaPods. See CocoaPods - Getting Started for further information.
  3. Prepare the project to be opened in Xcode:
    1. Navigate to the project’s root directory on the command line and download the project’s dependencies:
      $ cd forgerock-authenticator-ios
      $ pod install
      
    2. Open the project in Xcode:
      $ open ForgeRock.xcworkspace/
  4. Select the “ForgeRock” folder from the “Project Navigator View” in Xcode to view the app’s configuration in the main Xcode view.
  5. Update the App Identity settings:
    1. Bundle identifier, this should be the same as set in step 5b in the previous section, for example “com.acme.authenticator”.
    2. Version, for example “1.0.0”.
    3. Build, for example “1”.
  6. Update the App Signing settings:
    1. Enable “Automatically manage signing”; this is enabled for the official ForgeRock app.
    2. Team, this should refer to your Apple developer account.
    3. Provisioning profile, you should have a provisioning profile.
    4. Signing certificate, you should have a signing certificate.

Before making further changes, now would be a good time to verify that you are able to run the code on a physical device as detailed in Launch the App on an iPhone.

Dependency versions

Downloading the project's dependencies captures the versions in the Podfile.lock file (located in the project's root directory). This ensures that the same versions will be downloaded if the pod install command is re-run.

To update to a newer version of a dependency, you can use a combination of pod outdated to identify dependencies that are outdated and pod update to update them. See CocoaPods install vs update documentation for further details. If you make changes to third-party dependencies, you must also update the LIBRARIES file.

Launch the App on an iPhone

  1. Connect an iPhone to the laptop running Xcode.
  2. Accept the dialog displayed on your iPhone asking if you would like to trust your computer. 
  3. Select your phone from the devices dropdown in the top-left of Xcode.
  4. Select the “Play” icon.

Rename the project

  1. Select the “ForgeRock” folder from the “Project Navigator View” in Xcode to view the app’s configuration in the main Xcode view.
  2. Select the "File inspector" on the right hand-side; the name of your project should be in there under "Identity and Type":

  1. Change the name of your project to a new name, for example to “ACME”.
  2. Review the contents that will be renamed by Xcode and select “Rename”:

See How do I completely rename an Xcode project (i.e. inclusive of folders)? for further information on these steps.

Rename the scheme

  1. Click on the scheme for your OLD product (in the top bar near the "Stop" icon), then select "Manage schemes":

  1. Click on the OLD name in the scheme to make it editable and change the name:

See How do I completely rename an Xcode project (i.e. inclusive of folders)? for further information on these steps. 

Update the CocoaPods configuration

  1. Close Xcode.
  2. Open the Podfile (located in the project's root directory) in a text editor and update as follows:
    • Rename the target “ForgeRock”, for example to “ACME”.
    • Rename the target “ForgeRockTests”, for example to “ACMETests”:

  1. Navigate to the project’s root directory on the command line and and run the pod install command again to apply the CocoaPods changes:
    $ cd [project_root_dir]
    $ pod install
  2. Remove the ForgeRock.xcworkspace directory (also in the project’s root directory):
    $ rm -rf ForgeRock.xcworkspace
  3. Open the updated project in Xcode:
    $ open ACME.xcworkspace/

 

Rename the ForgeRock-Authenticator directory

  1. Close Xcode.
  2. Rename the directory using Git in order to preserve the history:
    $ git mv ForgeRock-Authenticator ACME-Authenticator
  3. Re-open the project in Xcode:
    $ open ACME.xcworkspace/
  4. Dismiss any warnings regarding missing files.
  5. Select “Authenticator” from the “Project Navigator View” in Xcode; it should be shown in red.
  6. Navigate to the Utilities pane under "Identity and Type" where you will see the "Name" entry.
  7. Select the folder icon to show a new dialog and update the location:

Rename the Entitlements file

  1. Rename the ForgeRock.entitlements file (located in the project's root directory), for example to ACME.entitlements:

Update the Build settings and rebuild

  1. Select the project from the “Project Navigator View” in Xcode.
  2. Select “General”, scroll down to the “Linked Frameworks and Libraries” section and remove the “libPods-ForgeRock.a” entry:

  1. Select "Build Settings", followed by “Packaging” and update the “Info.plist File” path, for example to “ACME-Authenticator/ACME-Info.plist”:

  1. Navigate to "Signing" and update the following:
    1. “Code Signing Entitlements” path, for example to “ACME.entitlements”.
    2. “Prefix header”, for example to “ACME-Authenticator/ACME-Prefix.pch”:

  1. Rebuild the project:
    1. Command + Shift + K to clean.
    2. Command + B to build.

Before making further changes, now would be a good time to verify that you are able to run the code on a physical device as detailed in Launch the App on an iPhone.

Update the Test Build settings

  1. Select the project from the “Project Navigator View” in Xcode.
  2. Select the “ACMETests” target in the main view.
  3. Select "Build Settings", followed by “Bundle Loader” and update the following:
    1. “Debug” path, for example to “$(BUILT_PRODUCTS_DIR)/ACME.app/ACME”.
    2. “Release” path, for example to “$(BUILT_PRODUCTS_DIR)/ACME.app/ACME”:

  1. Select “Build Phases”, followed by “Link Binary with Libraries” and remove the “libPods-ForgeRockTests.a” entry:

Update the Splashscreen video

  1. Replace the splashvideo.mp4 file (located in the [project_root_dir]/ACME-Authenticator directory) with the updated video file. Keeping the same filename means you do not have to update other project files.

Update App Permission Request dialogs

  1. Replace references to ForgeRock within the ACME-Info.plist file (located in the [project_root_dir]/ACME-Authenticator directory). For example, change them to ACME:

Update Localizable.strings

  1. Replace references to ForgeRock within the Localizable.strings file (located in the [project_root_dir]/ACME-Authenticator/en.lproj directory). For example, change them to ACME:

Update About.strings

  1. Replace relevant references to ForgeRock within the About.strings (located in the [project_root_dir]/ACME-Authenticator/Settings.bundle/en.lproj directory). For example, change them to ACME:

Note

ForgeRock and other copyright attributions should not be changed.

Update the App icon

  1. Generate a new set of icon files and a Contents.json file. These can be generated from a single source image using an online service such as https://appicon.co/.
  2. Replace the contents of the [project_root_dir]/ACME-Authenticator/Images.xcassets/AppIcon.appiconset/ directory with the set of icon files and a Contents.json file:

 

Update the Default Account icon

  1. Replace the forgerock-logo.png file (located in the [project_root_dir]/ACME-Authenticator directory) with an updated icon. If you want to change the name of this file, for example to acme-logo.png, then you must also update the references to it in the following files (using a text editor to find and replace is likely the easiest approach):
    • FRAUIUtils.m (located in the [project_root_dir]/ACME-Authenticator directory).
    • Main.storyboard (located in the [project_root_dir]/ACME-Authenticator directory)
    • project.pbxproj (located in the [project_root_dir]/ACME.xcodeproj directory):

Optional

You can delete the following files (located in the [project_root_dir]/ACME-Authenticator directory) from Xcode and the file system if you want as they are not used:

  • forgerock-logo-text.png 
  • forgerock-logo-opaque.png 

Update the Default colors

  1. Update colors in the following files (located in the [project_root_dir]/ACME-Authenticator directory); colors to update are specified in brackets:
    • FRANotificationsTableViewController.m (seaGreen and dashboardRed)
    • FRACircleProgressView.m (lightGrey)
    • FRAOathMechanismTableViewCellController.m (seaGreen and dashboardRed)
  2. Update colors and layout defined in the Main.storyboard file (located in the [project_root_dir]/ACME-Authenticator directory) if necessary.
Note

Any changes made to the Main.storyboard file will result in merge conflicts when rebasing over later changes to the official app; ForegRock's development approach allows edits to this file by only one developer at a time.

Publish your App

Once you have completed all your changes and rebuilt the app, you can submit your app to the Apple App Store. The following links provide useful Apple resources on the next steps:

Set up Push notifications

Refer to the following articles for further information on setting up Push notifications:

See Also

FAQ: Source code in AM/OpenAM

Xcode Help

CocoaPods Guides


Frequently Asked Questions


FAQ: Source code in AM/OpenAM

The purpose of this FAQ is to provide answers to commonly asked questions regarding source code and binaries in AM/OpenAM, including Enterprise and Maintenance releases.

Warning

ForgeRock support covers the use of the official binary builds made available and downloaded from our customer portal: BackStage. We will support builds made from source providing no changes have been made to the core code of the product, the product was built from a tag that matches an official release, for example, 6 and said product was built using the ForgeRock build scripts provided as part of the source. In the event that a customer experiences an issue with a ForgeRock product built from source where ForgeRock believe the issue is as a result of the build process, ForgeRock reserves the right to ask the customer to attempt to reproduce the issue on an official ForgeRock binary build. Customers who are running custom builds or who need further clarification should contact their ForgeRock sales representative.

Frequently asked questions

Q. How do I access source code for AM 5 and later?

A. The source code for ForgeRock Identity Platform 5 and later is in Git repositories hosted on our Bitbucket® Server. See Understanding source code access for ForgeRock products for further information.

The Git repositories have different access rights depending on what you are trying to do:

  • Extend AM functionality (such as the XUI, authentication nodes, authentication modules, the IdRepo, RADIUS code or the Push Notification framework). The code required for these customizations is available in the am-external repository. You do not need to sign the Enterprise Source Access (ESA) agreement. 
  • Build or customize ForgeRock Identity Platform 5 and later - you must sign the ESA as described in Understanding source code access for ForgeRock products (Signing the ESA agreement). See How do I build AM, DS, IDM and IG (All versions) from source? for further information. Modifying core parts of the platform is not recommended; it will leave you unsupported and often unable to apply critical security patches.
Note

You do not need access to source code to compile your own custom code, you just need access to the binaries in the ForgeRock protected Apache Maven™ repositories. See How do I access the ForgeRock protected Maven repositories? for further information. In essence, you just need to create a Java® project in Maven and use the ForgeRock binaries as Maven dependencies. Compiling custom code is outside the scope of ForgeRock support; if you want more tailored advice, consider engaging Professional Services.

Q. How do I access source code for older versions of OpenAM?

A. The source code for OpenAM 13.5.x and earlier is in Git repositories hosted on our Bitbucket Server. See Understanding source code access for ForgeRock products for further information.

You can clone it from Bitbucket using Git:

$ git clone [URL]
Note

To clone the source code with a SSH URL, you must have created a SSH key and added it to your Bitbucket profile.

Some useful URLs are:

  • OpenAM enterprise releases - ssh://git@stash.forgerock.org:7999/openam/openam-public.git
  • OpenAM maintenance releases - ssh://git@stash.forgerock.org:7999/openam/openam-sustaining-external.git

For example, to clone the OpenAM source code for an enterprise release from Bitbucket, you would use the following command:

$ git clone ssh://git@stash.forgerock.org:7999/openam/openam-public.git

And then navigate to the relevant tag, for example 13.0.0.

Alternatively, you can use a GUI Git client of your choice, for example, SourceTree.

Q. What credentials do I use to log into Bitbucket?

A. You can log into Bitbucket with your BackStage username and password. Your BackStage username is different to your email address.

Note

You can log into BackStage using either your email address or username, but you must use your username to log into Bitbucket.

You must also be authenticated to access the Maven repositories; see How do I access the ForgeRock protected Maven repositories? for further information. 

Q. How do I access nightly builds and documentation?

A. You can access nightly builds (binaries) and documentation as detailed in How do I access nightly builds and documentation for ForgeRock products?

Q. How do I access the source code for the ForgeRock Authenticator app?

A. You can access the source code for the ForgeRock Authenticator app from the following URLs:

See How do I update and recompile the iOS authenticator app with custom branding in AM (All versions)? for further information on branding the iOS app. 

Q. How do I access the source code for ForgeRock Commons?

A. The source code for ForgeRock Commons is available in different repositories depending on version. See Where can I find source code for Commons (All versions) for further information.

For ForgeRock Commons 21 and above (used to build ForgeRock Identity Platform 5 and later), you need to sign the Enterprise Source Access agreement as described in Understanding source code access for ForgeRock products to get access.

See Also

How do I access the ForgeRock protected Maven repositories?

FAQ: Installing AM/OpenAM

FAQ: Upgrading AM/OpenAM

How do I build OpenAM 12.x and 13.x from source?

Source code in ForgeRock products


FAQ: Source code in DS/OpenDJ

The purpose of this FAQ is to provide answers to commonly asked questions regarding source code and binaries in DS/OpenDJ, including Enterprise and Maintenance releases.

Warning

ForgeRock support covers the use of the official binary builds made available and downloaded from our customer portal: BackStage. We will support builds made from source providing no changes have been made to the core code of the product, the product was built from a tag that matches an official release, for example, 6 and said product was built using the ForgeRock build scripts provided as part of the source. In the event that a customer experiences an issue with a ForgeRock product built from source where ForgeRock believe the issue is as a result of the build process, ForgeRock reserves the right to ask the customer to attempt to reproduce the issue on an official ForgeRock binary build. Customers who are running custom builds or who need further clarification should contact their ForgeRock sales representative.

Frequently asked questions

Q. How do I access source code for DS 5 and later?

A. The source code for ForgeRock Identity Platform 5 and later is in Git repositories hosted on our Bitbucket® Server. See Understanding source code access for ForgeRock products for further information.

To build or customize ForgeRock Identity Platform 5 and later, you must sign the Enterprise Source Access (ESA) agreement as described in Understanding source code access for ForgeRock products (Signing the ESA agreement). See How do I build AM, DS, IDM and IG (All versions) from source? for further information. Modifying core parts of the platform is not recommended; it will leave you unsupported and often unable to apply critical security patches.

Note

You do not need access to source code to compile your own custom code, you just need access to the binaries in the ForgeRock protected Apache Maven™ repositories. See How do I access the ForgeRock protected Maven repositories? for further information. In essence, you just need to create a Java® project in Maven and use the ForgeRock binaries as Maven dependencies. Compiling custom code is outside the scope of ForgeRock support; if you want more tailored advice, consider engaging Professional Services.

Q. How do I access source code for older versions of OpenDJ?

A. The source code for OpenDJ (3.5.x and earlier) enterprise and maintenance releases is in Git repositories hosted on our Bitbucket Server. See Understanding source code access for ForgeRock products for further information.

You can clone it from Bitbucket using Git:

$ git clone [URL]
Note

To clone the source code with a SSH URL, you must have created a SSH key and added it to your Bitbucket profile.

Some useful URLs are:

  • OpenDJ enterprise releases - ssh://git@stash.forgerock.org:7999/opendj/opendj-public.git
  • OpenDJ maintenance releases - ssh://git@stash.forgerock.org:7999/opendj/opendj-sustaining-external.git

For example, to clone the OpenDJ source code for an enterprise release from Bitbucket, you would use the following command:

$ git clone ssh://git@stash.forgerock.org:7999/opendj/opendj-public.git

And then navigate to the relevant tag, for example, 3.0.0.

Alternatively, you can use a GUI Git client of your choice, for example, SourceTree.

Q. What credentials do I use to log into Bitbucket?

A. You can log into Bitbucket with your BackStage username and password. Your BackStage username is different to your email address.

Note

You can log into BackStage using either your email address or username, but you must use your username to log into Bitbucket.

You must also be authenticated to access the Maven repositories; see How do I access the ForgeRock protected Maven repositories? for further information.  

Q. How do I access nightly builds and documentation?

A. You can access nightly builds (binaries) and documentation as detailed in How do I access nightly builds and documentation for ForgeRock products?

Q. How do I access the source code for ForgeRock Commons?

A. The source code for ForgeRock Commons is available in different repositories depending on version. See Where can I find source code for Commons (All versions) for further information.

For ForgeRock Commons 21 and above (used to build ForgeRock Identity Platform 5 and later), you need to sign the Enterprise Source Access agreement as described in Understanding source code access for ForgeRock products to get access.

See Also

How do I access the ForgeRock protected Maven repositories?

FAQ: Installing and configuring DS/OpenDJ

FAQ: Upgrading DS/OpenDJ


FAQ: Source code in IDM/OpenIDM

The purpose of this FAQ is to provide answers to commonly asked questions regarding source code and binaries in IDM/OpenIDM, including Enterprise and Maintenance releases.

Warning

ForgeRock support covers the use of the official binary builds made available and downloaded from our customer portal: BackStage. We will support builds made from source provided no changes have been made to the core code of the product, the product was built from a tag that matches an official release, for example 6, and said product was built using the ForgeRock build scripts provided as part of the source. In the event that a customer experiences an issue with a ForgeRock product built from source where ForgeRock believe the issue is as a result of the build process, ForgeRock reserves the right to ask the customer to attempt to reproduce the issue on an official ForgeRock binary build. Customers who are running custom builds or who need further clarification should contact their ForgeRock sales representative.

Frequently asked questions

Q. How do I access source code for IDM 5 and later?

A. The source code for ForgeRock Identity Platform 5 and later is in Git repositories hosted on our Bitbucket® Server. See Understanding source code access for ForgeRock products for further information.

To build or customize ForgeRock Identity Platform 5 and later, you must sign the Enterprise Source Access (ESA) agreement as described in Understanding source code access for ForgeRock products (Signing the ESA agreement). See How do I build AM, DS, IDM and IG (All versions) from source? for further information. Modifying core parts of the platform is not recommended; it will leave you unsupported and often unable to apply critical security patches.

Note

You do not need access to source code to compile your own custom code, you just need access to the binaries in the ForgeRock protected Apache Maven™ repositories. See How do I access the ForgeRock protected Maven repositories? for further information. In essence, you just need to create a Java® project in Maven and use the ForgeRock binaries as Maven dependencies. Compiling custom code is outside the scope of ForgeRock support; if you want more tailored advice, consider engaging Professional Services.

Q. How do I access source code for older versions of OpenIDM?

A. The source code for OpenIDM (4.5 and earlier) enterprise and maintenance releases is in Git repositories hosted on our Bitbucket Server. See Understanding source code access for ForgeRock products for further information.

You can clone it from Bitbucket using Git:

$ git clone [URL]
Note

To clone the source code with a SSH URL, you must have created a SSH key and added it to your Bitbucket profile.

Some useful URLs are:

  • OpenIDM enterprise releases - ssh://git@stash.forgerock.org:7999/openidm/openidm-public.git
  • OpenIDM maintenance releases - ssh://git@stash.forgerock.org:7999/openidm/openidm-sustaining-external.git

For example, to clone the OpenIDM source code for an enterprise release from Bitbucket, you would use the following command:

$ git clone ssh://git@stash.forgerock.org:7999/openidm/openidm-public.git

And then navigate to the relevant tag, for example, 4.0.0.

Alternatively, you can use a GUI Git client of your choice, for example, SourceTree.

Q. What credentials do I use to log into Bitbucket?

A. You can log into Bitbucket with your BackStage username and password. Your BackStage username is different from your email address.

Note

You can log into BackStage using either your email address or username, but you must use your username to log into Bitbucket.

You must also be authenticated to access the Maven repositories; see How do I access the ForgeRock protected Maven repositories? for further information. 

Q. How do I access nightly builds and documentation?

A. You can access nightly builds (binaries) and documentation as detailed in How do I access nightly builds and documentation for ForgeRock products?

Q. How do I access the source code for ForgeRock Commons?

A. The source code for ForgeRock Commons is available in different repositories depending on version. See Where can I find source code for Commons (All versions) for further information.

For ForgeRock Commons 21 and above (used to build ForgeRock Identity Platform 5 and later), you need to sign the Enterprise Source Access agreement as described in Understanding source code access for ForgeRock products to get access.

See Also

How do I access the ForgeRock protected Maven repositories?

FAQ: Upgrading IDM/OpenIDM


FAQ: Source code in IG/OpenIG

The purpose of this FAQ is to provide answers to commonly asked questions regarding source code and binaries in IG/OpenIG, including Enterprise and Maintenance releases.

Warning

ForgeRock support covers the use of the official binary builds made available and downloaded from our customer portal: BackStage. We will support builds made from source providing no changes have been made to the core code of the product, the product was built from a tag that matches an official release, for example, 6 and said product was built using the ForgeRock build scripts provided as part of the source. In the event that a customer experiences an issue with a ForgeRock product built from source where ForgeRock believe the issue is as a result of the build process, ForgeRock reserves the right to ask the customer to attempt to reproduce the issue on an official ForgeRock binary build. Customers who are running custom builds or who need further clarification should contact their ForgeRock sales representative.

Frequently asked questions

Q. How do I access source code for IG 5 and later?

A. The source code for ForgeRock Identity Platform 5 and later is in Git repositories hosted on our Bitbucket® Server. See Understanding source code access for ForgeRock products for further information.

To build or customize ForgeRock Identity Platform 5 and later, you must sign the Enterprise Source Access (ESA) agreement as described in Understanding source code access for ForgeRock products (Signing the ESA agreement). See How do I build AM, DS, IDM and IG (All versions) from source? for further information. Modifying core parts of the platform is not recommended; it will leave you unsupported and often unable to apply critical security patches.

Note

You do not need access to source code to compile your own custom code, you just need access to the binaries in the ForgeRock protected Apache Maven™ repositories. See How do I access the ForgeRock protected Maven repositories? for further information. In essence, you just need to create a Java® project in Maven and use the ForgeRock binaries as Maven dependencies. Compiling custom code is outside the scope of ForgeRock support; if you want more tailored advice, consider engaging Professional Services.

Q. How do I access source code for older versions of OpenIG?

A. The source code for OpenIG (4.5 and earlier) enterprise and maintenance releases is in Git repositories hosted on our Bitbucket Server. See Understanding source code access for ForgeRock products for further information.

You can clone it from Bitbucket using Git:

$ git clone [URL]
Note

To clone the source code with a SSH URL, you must have created a SSH key and added it to your Bitbucket profile.

Some useful URLs are:

  • OpenIG enterprise releases - ssh://git@stash.forgerock.org:7999/openig/openig-public.git
  • OpenIG maintenance releases - ssh://git@stash.forgerock.org:7999/openig/openig-sustaining-external.git

For example, to clone the OpenIG source code for an enterprise release from Bitbucket, you would use the following command:

$ git clone ssh://git@stash.forgerock.org:7999/openig/openig-public.git

And then navigate to the relevant tag, for example, 4.0.0.

Alternatively, you can use a GUI Git client of your choice, for example, SourceTree.

Q. What credentials do I use to log into Bitbucket?

A. You can log into Bitbucket with your BackStage username and password. Your BackStage username is different to your email address.

Note

You can log into BackStage using either your email address or username, but you must use your username to log into Bitbucket.

You must also be authenticated to access the Maven repositories; see How do I access the ForgeRock protected Maven repositories? for further information. 

Q. How do I access nightly builds and documentation?

A. You can access nightly builds (binaries) and documentation as detailed in How do I access nightly builds and documentation for ForgeRock products?

Q. How do I access the source code for ForgeRock Commons?

A. The source code for ForgeRock Commons is available in different repositories depending on version. See Where can I find source code for Commons (All versions) for further information.

For ForgeRock Commons 21 and above (used to build ForgeRock Identity Platform 5 and later), you need to sign the Enterprise Source Access agreement as described in Understanding source code access for ForgeRock products to get access.

See Also

How do I access the ForgeRock protected Maven repositories?

FAQ: Installing and configuring IG/OpenIG

Source code in ForgeRock products


Known Issues


Building from source fails with The exception was thrown with the wrong message when system locale is not English

The purpose of this article is to provide assistance if building from source using Apache Maven™ fails with the following exception when the system locale is not English: "FAILURE! org.testng.TestException: The exception was thrown with the wrong message". This article applies to all ForgeRock products (AM/OpenAM, Policy Agents, DS/OpenDJ, IDM/OpenIDM and IG/OpenIG).

Warning

ForgeRock support covers the use of the official binary builds made available and downloaded from our customer portal: BackStage. We will support builds made from source providing no changes have been made to the core code of the product, the product was built from a tag that matches an official release, for example, 5.5 and said product was built using the ForgeRock build scripts provided as part of the source. In the event that a customer experiences an issue with a ForgeRock product built from source where ForgeRock believe the issue is as a result of the build process, ForgeRock reserves the right to ask the customer to attempt to reproduce the issue on an official ForgeRock binary build. Customers who are running custom builds or who need further clarification should contact their ForgeRock sales representative.

Symptoms

The Maven build fails and you see a message similar to the following, where the English message is shown followed by the equivalent in a different language:

  • French example:
    ------------------------------------------------------- 
    T E S T S 
    ------------------------------------------------------- 
    Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=96m; support was removed in 8.0 
    Running TestSuite 
    Tests run: 170, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 5.3 sec <<< FAILURE! - in TestSuite 
    shouldForbidChangingIntegerCache(org.forgerock.openam.scripting.StandardScriptEvaluatorTest) Time elapsed: 0.081 sec <<< FAILURE! 
    org.testng.TestException: 
    The exception was thrown with the wrong message: expected ".*Access to Java class .*? is prohibited.*" but got "L'accès à la classe Java "java.lang.Class" est prohibé. (<Unknown source>#1) in <Unknown source> at line number 1 at column number 0" 
    
  • Spanish example:
    ------------------------------------------------------- 
    T E S T S 
    ------------------------------------------------------- 
    Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=96m; support was removed in 8.0 
    Running TestSuite 
    Tests run: 170, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 5.3 sec <<< FAILURE! - in TestSuite 
    shouldForbidChangingIntegerCache(org.forgerock.openam.scripting.StandardScriptEvaluatorTest) Time elapsed: 0.081 sec <<< FAILURE! 
    org.testng.TestException: 
    The exception was thrown with the wrong message: expected "Invalid value DELETE for property actionValues" but got "Valor no válido DELETE para propiedad actionValues"
    

Recent Changes

Changed the system locale to a non-English locale.

Causes

Some error messages are hard-coded in English. When Maven attempts to display them in a different language (as determined by your system locale), it fails and generates this exception.

Solution

This issue can be resolved using one of the following approaches:

  • Exclude the unit tests when building from source. This can be achieved using the following command:
    $ mvn install -DskipTests
  • Add the -Duser.language=en option to the root pom.xml file and rebuild. This option should be added to the java.surefire.options property. For example:
    <java.surefire.options>-Xms256m -Xmx256m -XX:MaxPermSize=96m -Duser.language=en</java.surefire.options>
    

See Also

Source code in ForgeRock products

Related Training

N/A

Related Issue Tracker IDs

OPENAM-8182 (Maven build fails if system locale is not en_US)


Aether ClassNotFound when building Policy Agents and OpenAM 12.x, 13 from source

The purpose of this article is to provide assistance if you receive a java.lang.NoClassDefFoundError: org/sonatype/aether/* when building Policy Agents and OpenAM from source using Apache Maven™ 3.1.0.

Warning

ForgeRock support covers the use of the official binary builds made available and downloaded from our customer portal: BackStage. We will support builds made from source providing no changes have been made to the core code of the product, the product was built from a tag that matches an official release, for example, 13 and said product was built using the ForgeRock build scripts provided as part of the source. In the event that a customer experiences an issue with a ForgeRock product built from source where ForgeRock believe the issue is as a result of the build process, ForgeRock reserves the right to ask the customer to attempt to reproduce the issue on an official ForgeRock binary build. Customers who are running custom builds or who need further clarification should contact their ForgeRock sales representative.

Symptoms

You will see errors that refer to:

java.lang.NoClassDefFoundError: org/sonatype/aether/*
Caused by: java.lang.ClassNotFoundException: org.sonatype.aether.*

An example error could be as follows when attempting to build from source:

[INFO] Dependency-reduced POM written at: /home/ArchiSecu/temp/openam-agents/jee-agents/jee-agents-jboss/jee-agents-jboss-v40/dependency-reduced-pom.xml 
[WARNING] Error injecting: org.apache.maven.shared.dependency.graph.internal.Maven3DependencyGraphBuilder 
java.lang.NoClassDefFoundError: org/sonatype/aether/version/VersionConstraint 
   at java.lang.Class.getDeclaredMethods0(Native Method) 
   at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) 
   at java.lang.Class.getDeclaredMethods(Class.java:1791) 
   at com.google.inject.spi.InjectionPoint.getInjectionPoints(InjectionPoint.java:674) 
   at com.google.inject.spi.InjectionPoint.forInstanceMethodsAndFields(InjectionPoint.java:366) 
   at com.google.inject.internal.ConstructorBindingImpl.getInternalDependencies(ConstructorBindingImpl.java:165)
...
Caused by: java.lang.ClassNotFoundException: org.sonatype.aether.version.VersionConstraint 
   at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50) 
   at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:259) 
   at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:242) 
   at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:227) 
...

Recent Changes

N/A

Causes

This is a known issue that exists in Maven 3.1.0. This error is caused by the Maven 3.1-alpha-1 migration from Sonatype Aether to Eclipse Aether, which is an incompatible change for some plugins. You can use this link AetherClassNotFound to check the current status of this issue from Apache.

Solution

This issue can be resolved by upgrading the affected plugins if you use Maven 3.0.x or 3.1.x. AetherClassNotFound lists the affected plugins and the corresponding minimum needed version.

Alternatively, you can downgrade to Maven 3.0.5. You can download Maven from: Download Apache Maven.

See Also

FAQ: Source code in AM/OpenAM

Source code in ForgeRock products

AetherClassNotFound

Related Training

N/A

Related Issue Tracker IDs

OPENAM-2834 (Build issues with Maven 3.1.0)

OPENAM-4451 (Java EE agents can't be compiled using Maven 3.1.0+)


Copyright and TrademarksCopyright © 2018 ForgeRock, all rights reserved.

This content has been optimized for printing.

Loading...