Push Services in AM/OpenAM

This book provides information on push services in AM/OpenAM.

How do I set up AM/OpenAM Push Notification Service credentials?

This article explains how to use BackStage to provision credentials for the AM/OpenAM Push Notification Service.

About Push Notifications in AM/OpenAM

OpenAM 13.5 introduced a new passwordless authentication module that uses push notifications. This module relies on a cloud based notification service provided by ForgeRock to AM/OpenAM customers.

The ForgeRock Authenticator (Push) authentication module introduced in OpenAM 13.5 provides authentication using an additional factor, for example a phone running Android™ or iOS® and the ForgeRock Authenticator app.

The ForgeRock Authenticator (Push) authentication module sends messages through an online push notification service called SNS (provided by Amazon AWS™), which delegates push messages to APNS (Apple Push Notification Service) for iOS devices and GCM (Google Cloud Messaging) for Android devices.

ForgeRock customers who have subscribed for the Push Authentication module for AM/OpenAM can provision Push Authentication credentials in BackStage. Only credentials created via BackStage can be used with the official ForgeRock Authenticator App available in the Apple® App Store and the Google® Play Store.


If you are a ForgeRock customer and AM/OpenAM is part of your subscription, but you do not have access to Push Authentication credentials in BackStage, it means that your contract currently does not include the Push Authentication (AM-PUSH-AUTH) module. To add this module to your subscription, please contact your account manager or our sales team at sales@forgerock.com.

Push Notification Service Credentials

The credentials required for the Push Notification Service are the following:

  • Amazon IAM User (“sub-account”)
    • AWS Key ID
    • AWS Key Secret
  • Amazon SNS Endpoints
    • GCM Endpoint (identified by an ARN)
    • APNS Endpoint (identified by an ARN)​
  • Amazon AWS Region

A set of credentials (and endpoints) can be created for an environment. Each subscription can have multiple projects and each project can have multiple environments, but each environment can only have a single set of credentials, see Working with Projects in BackStage and Working with Environments in BackStage.

Push Notification Service credentials cannot be provisioned for your private projects (that is, projects that are not owned by a subscription).

If your subscriptions do not have any projects, a project must be created first. If the selected project does not have any environments, an environment must also be created before credentials can be provisioned.

To create a project, go to https://backstage.forgerock.com/support/projects/. To create an environment, navigate to an existing project’s details page and click “new environment”.


While you can only provision a single set of credentials per environment, there is no limit to the number of environments a project can have.


BackStage stores each set of credentials created (along with some audit data such as user ID and a timestamp), but it does NOT store the secret key. The secret key must therefore be copied and saved by the user who requested the credentials before they leave or refresh the page.

Provisioning Credentials

To provision Push Notification Service credentials for an environment, go to https://backstage.forgerock.com/support/projects/, select (or create) a project, then scroll down to the Environments section and select (or create) an environment.

On the environment details page, scroll down to the Cloud Services section. Under Cloud Services, you should see a panel entitled OpenAM Push Authentication.


If you selected an environment that belongs to a private project or the subscription doesn't have a valid AM/OpenAM subscription, the OpenAM Push Authentication section will not be available.

If there are not credentials for this environment yet, there will be a button labeled Set up Push Auth Credentials.

Clicking the Set up Push Auth Credentials button opens a modal dialog where you can fill in a description, and then submit your provisioning request by clicking Submit.

Once created, the credentials will appear in a modal dialog.


You must save the secret key as it will not be stored by BackStage. There is no way to recover a lost or forgotten secret key.


You must select the correct SNS Client Region (us-east-1).

After the credentials have been provisioned, the controls on environment details page change to allow showing or deleting the credentials.

Credentials can be viewed after they have been created, but the access key secret is no longer there.

Deprovisioning Credentials

Credentials for each environment can be deprovisioned by the user who created the credentials or by any admin member of the subscription that owns the credentials. However, customers can have an unlimited number of projects and environments in BackStage.

Deprovisioning a set of credentials will remove the Amazon IAM user, the policies and SNS endpoints from Amazon, but will keep a record of the credentials in the BackStage database for audit purposes.

BackStage runs an automated task every day to check if there are any Push Auth credentials for customers without a valid subscription. If BackStage finds that a subscription has expired one month ago, it will automatically deprovision any Push Auth credentials that are owned by that subscription.

If the credentials were deprovisioned manually, members of the subscription have the option to provision a new set of credentials for the same environment.

See Also

How do I use my own AWS SNS Push Service with AM (All versions) and OpenAM 13.5?

How do I use Push notifications in AM (All versions) and OpenAM 13.5 with a non-AWS SNS Push Service?

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

How do I use my own AWS SNS Push Service with AM (All versions) and OpenAM 13.5?

The purpose of this article is to provide information on using your own Amazon Web Services™ (AWS™) SNS Push Service with AM/OpenAM.


Push Messages are a (relatively) easy way to communicate with a mobile phone. While similar to SMS messages, they are considered to be more secure and NIST (National Institute of Standards and Technology), for example, recommends favoring push messages over traditional SMS messages.

AM/OpenAM provides push authentication as a secure authentication mechanism, which can utilize the TouchID of modern phones (iOS® and Android™). ForgeRock also provides a mobile app, which can:

  • Register a smartphone for use with push authentication.
  • Receive Push messages and authenticate the user using the TouchID fingerprint mechanism.

This app (ForgeRock Authenticator) is available on both the Apple® App Store and Google® Play Store. ForgeRock provides a push notification service via AWS SNS. ForgeRock customers can easily subscribe to this service, which sends out push messages from both cloud-based and on-premise based AM/OpenAM installations. See How do I set up AM/OpenAM Push Notification Service credentials? for further details.

The need for customization

The push messages technology needs the messaging service to know exactly which mobile app the message should be sent to. For iOS, the mobile app is identified by a so-called bundle identifier. This bundle ID cannot be changed once the developer has signed the app and submitted it to the App Store. As a result, the configuration of the message service must be changed whenever the app is modified and vice versa. This requirement prevents people who do not own or develop the app from sending push messages to other apps (for example, this prevents a potentially hostile entity sending messages to apps such as LinkedIn or WhatsApp).

In summary:

  • If you want to modify the app, you have to use your own AWS SNS service.
  • If you want to use your own AWS SNS service, you have to modify/recompile the app with a new bundle ID.

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. 

How to create your own SNS service

The following sections explain how to create your own SNS service and how to connect to the Apple Push Notification Service (APNS) as well as Google Cloud Messaging (GCM):

  1. Create a keypair
  2. Create a GCM service
  3. Create a SNS service

If you experience issues registering the new app with the new SNS service, see the Debugging section for further help.


To set up AWS SNS you need:

  • A valid AWS account
  • An Apple Developer account
  • A Google Firebase account

Creating a keypair

First you need to create a public/private keypair that will be uploaded as a .p12 file to AWS. AWS uses this keypair to authenticate against APNS. You can, for example, use the Keychain app on Mac OS X to generate the keypair as demonstrated here:

  1. Navigate to the Apple Developer page (developer.apple.com) and log in with your iOS developer account; select Certificates, IDs & Profiles.
  2. Create an XCode project, enable Push Notifications and choose a new bundle ID. Alternatively, you can check out the ForgeRock Authenticator app (iOS or Android) and amend the bundle ID. 

The bundle ID should now show up in Apple developer console “iOS App IDs”. 

  1. Create the keypair that AWS uses to access APNS. Add a development or production certificate for Push Notifications. Then add a certificate for APNS:

  1. Select which application should receive the push notifications. Since an app is identified by the App ID (which matches the Bundle ID) we need to select the Bundle ID we entered in step 2 (io.push.demo in this example):

  1. The Apple wizard will now guide you through the steps using the Keychain app to generate a CSR (Certificate Signing Request), submit it to Apple CA via the developer console, download it and then import it into the Keychain. The new certificate will appear with type “Apple Push Services” in the Apple developer certificates section:

  1. Create a PKCS12 version from the Keychain app, which has the public and private parts in one file. This file will be uploaded to your AWS SNS later:

This completes the preparation for iOS.

Creating a GCM service

Recently Google moved the creation of a GCM service to the Firebase console. You need a Google cloud account to access this console.

You can create a GCM service as follows:

  1. Navigate to the Firebase console (console.firebase.google.com) and log in with your Google cloud account.
  2. Create a new project:

  1. Open settings:

The project ID and an API key are on the page that follows. You’ll need the API key in the next step to access GCM from the AWS SNS service.

Creating a SNS service

You can create a SNS service as follows:

  1. Navigate to the AWS console (aws.amazon.com/console) and then go to AWS service and select Simple Notification Service (SNS):

  1. Select Create platform application. You’ll now have to provide the data to access APNS and GCM services. For APNS, do:

  1. Select “Choose P12 file”, provide the password that protects the file (remember that this file contains both your private and public key) and click “Load credentials from file”. The field containing certificates and private key should now be auto-populated.
  2. Configure access to GCM accordingly. GCM uses an API key rather than a P12 but this is basically the same approach:

If all goes well, your AWS SNS application will show up under applications together with their endpoint. These endpoints look like the following and need to be entered in the AM/OpenAM Push Service configuration:


To prevent people accessing the endpoints in AWS for APNS or GCM, these endpoint are protected with a clientID/clientSecret pair. To generate such a pair, you need to create a user via the AWS console using the IAM service. Make sure you tick the box for programmatic access.

  1. Click on “Attach existing policies directly” area and select the “AmazonSNSFullAccess” policy:

  1. Select the user and retrieve the Access Key ID and Secret Access Key from the IAM console. You can download these values as a CSV file:

That’s it. You can now configure the AM/OpenAM’s push service to use these values and test it. See the following links for further information:


If something goes wrong with registering the new app with the new SNS service, you can test if the app can receive push messages that are not issued by AM/OpenAM.


You should also try updating the AWS SDK jar files to the latest version to ensure there are no jar incompatibilities. You should obtain the latest aws-java-sdk-core-<version>.jaraws-java-sdk-sns-<version>.jar and aws-java-sdk-sqs-<version>.jar files, copy them to the /path/to/tomcat/webapps/openam/WEB-INF/lib directory and delete the old jar files.

To do this, you can test push messages using Amazon’s AWS SDK: 

  1. Download the ForgeRock authenticator’s source code: iOS or Android.
  2. Replace the bundle ID as described earlier. Attach your iOS device to your Mac and run the app while the mobile phone is connected to XCode. Once you have allowed Push Notifications to be received, you’ll see something similar to the following in the XCode console’s output:
    2017–07–20 08:46:29.111970+0200 ForgeRock[7354:2548462] Registered for remote notifications. deviceToken=<8e0729bb 565fbddc bde0bd42 e06ecf2 4464f063 7932a580 73add12c ee6e3af7>’
    The deviceToken is a sort of phone number that SNS must know in order to send a message to this specific device. This is exactly what happens during the the QR registration step. After a successful registration, the AM/OpenAM’s profile for the push user will have a pushDeviceProfiles attribute that contains the deviceToken (among other data).
  3. Try to send push message to your device using the AWS console or a NodeJS program (for example, tmarshall - aws-sns-example.js).

AWS console 

  1. Navigate to the AWS console (aws.amazon.com/console) and then go to SNS service:

  1. Select your application. Click on the correct ARN (for example, iOS for Apple devices). Now click on Create Endpoint (this will add a device specific endpoint).

  1. Enter the deviceToken without spaces (you can leave the User Data field empty) and publish a message to this endpoint (for example, “Long live Rock’n’Roll”). You should now receive this message on your phone.


To use NodeJS code, simply set the following parameters to match your environment:

  • SNS Endpoints of the application
  • ID/Secret to access AWS
  • deviceToken
  • region (for example, us-east-1) where you created your service 

See Also

How do I set up AM/OpenAM Push Notification Service credentials?

Using Push Notifications for Passwordless Authentication and Easy MFA

Using your own SNS messaging with ForgeRock Authenticator

Related Training

ForgeRock Access Management Core Concepts (AM-400)

Related Issue Tracker IDs


User cannot log in using Push authentication in AM (All versions) and OpenAM 13.5

The purpose of this article is to provide assistance if a user cannot log in using Push authentication in AM/OpenAM.


The user cannot log in using Push authentication.

You see the following error when a user attempts to log in using Push authentication:

{"code":500,"reason":"Internal Server Error","message":"Authentication Error!!"}

An error similar to the following is shown in the CoreSystem debug log when this happens:

Formatted event: "de6427e2-4671-9359-aff9-bac00cd4c431-311","2018-03-04T12:21:28.554Z","AM-LOGIN-COMPLETED","de6427e2-4671-9359-aff9-bac00cd4c431-305",,"[""c3f6d35deec82a4031""]","FAILED",,,"[{""moduleId"":""pushAuth"",""info"":{""authIndex"":""service"",""failureReason"":""LOGIN_FAILED"",""ipAddress"":"""",""authLevel"":""2""}}]","Authentication","/"

You may also see the following error in the Push debug logs:

Received error response: com.amazonaws.services.sns.model.EndpointDisabledException: Endpoint is disabled (Service: AmazonSNS; Status Code: 400; Error Code: EndpointDisabled; Request ID: 1431e de2-94b3-2d50-6e21-bc9c8f3931f7)

The endpoint referred to in this error is the end user's device (for example, mobile) endpoint.

Recent Changes



The majority of issues with Push authentication are caused by changes to the end user's device. Common reasons include (although not limited to):

  • The device has been restored from a backup.
  • The relevant app has been reinstalled on the device.
  • The user has disabled push notifications.

These changes result in the end user's device (endpoint) being disabled in AWS.

See Stack Overflow - Getting “EndpointDisabled” from Amazon SNS for information on other causes for the "Endpoint is disabled" error.


This issue, regardless of the exact cause, can typically be resolved by re-registering the device. This process initiates a search for the endpoint and results in it being re-enabled in AWS. 


Please observe the following when constructing REST calls:

  • Make the REST call to the actual AM/OpenAM server URL (not lb).
  • Change the name of the iPlanetDirectoryPro header to the name of your actual session cookie.
  • Set this session cookie header to the token returned when you authenticated.
  • Ensure the Accept-API-Version header contains a valid resource version (AM 5 and later).

See How do I avoid common issues with REST calls in AM/OpenAM (All versions)? for further information.

You can re-register the device as follows:

  1. Authenticate as an admin user. For example:
    • AM 5 and later:
      $ curl -X POST -H "X-OpenAM-Username: amadmin" -H "X-OpenAM-Password: cangetinam" -H "Content-Type: application/json" -H "Accept-API-Version: resource=2.1" http://host1.example.com:8080/openam/json/realms/root/authenticate
    • Pre-AM 5:
      $ curl -X POST -H "X-OpenAM-Username: amadmin" -H "X-OpenAM-Password: cangetinam" -H "Content-Type: application/json" http://host1.example.com:8080/openam/json/authenticate
    Example response:
    { "tokenId": "AQIC5wM2LY4SfcxsuvGEjcsppDSFR8H8DYBSouTtz3m64PI.*AAJTSQACMDIAAlNLABQtNTQwMTU3NzgxODI0NzE3OTIwNAEwNDU2NjE0*", "successUrl": "/openam/console", "realm": "/" } 
  2. Remove the device from the user's profile using one of the following curl commands where myUser in the URL is replaced with the name of the user:
    • AM 5 and later:
      $ curl -X POST -H "Content-Type: application/json" -H "Accept-API-Version: resource=3.0" -H "iPlanetDirectoryPro: AQIC5wM2LY4Sfcxs...EwNDU2NjE0*" http://host1.example.com:8080/openam/json/realms/root/users/myUser/devices/push?_action=reset
    • Pre-AM 5:
      $ curl -X POST -H "Content-Type: application/json" -H "iPlanetDirectoryPro: AQIC5wM2LY4Sfcxs...EwNDU2NjE0*" http://host1.example.com:8080/openam/json/users/myUser/devices/push?_action=reset
  3. Ask the user to re-register their device.

See Also

How do I set up AM/OpenAM Push Notification Service credentials?

How do I use my own AWS SNS Push Service with AM (All versions) and OpenAM 13.5?

Authentication and Single Sign-On Guide › About Push Authentication

Authentication and Single Sign-On Guide › Creating Authentication Chains for Push Authentication

Authentication and Single Sign-On Guide › ForgeRock Authenticator (Push) Registration Authentication Module

Authentication and Single Sign-On Guide › Resetting Registered Devices by using REST

How do I troubleshoot failed Amazon SNS push notification deliveries?

Related Training


Related Issue Tracker IDs

OPENAM-12043 (Trigger SNS endpoint enablement when a recovery code is used)

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.


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.


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).


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


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:


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):


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.

Any changes made to the Main.storyboard file will result in merge conflicts when rebasing over later changes to the official app; ForgeRock'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

Copyright and TrademarksCopyright © 2018 - 2019 ForgeRock, all rights reserved.

This content has been optimized for printing.