When I shut down docker image (#61) it hangs indefinitely due to the following thread:

"Thread-1" #33 prio=5 os_prio=0 cpu=19.86ms elapsed=90.87s tid=0x00007f03740209a0 nid=0x265 waiting on condition  [0x00007f03685fc000]
   java.lang.Thread.State: TIMED_WAITING (parking)
        at jdk.internal.misc.Unsafe.park([email protected]/Native Method)
        - parking to wait for  <0x00000000bba8ec00> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.parkNanos([email protected]/LockSupport.java:252)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos([email protected]/AbstractQueuedSynchronizer.java:1672)
        at java.util.concurrent.ArrayBlockingQueue.poll([email protected]/ArrayBlockingQueue.java:435)
        at org.forgerock.openam.cts.impl.queue.AsyncResultHandler.getResults(AsyncResultHandler.java:86)
        at org.forgerock.openam.cts.monitoring.impl.queue.TokenMonitoringResultHandler.getResults(TokenMonitoringResultHandler.java:50)
        at org.forgerock.openam.cts.monitoring.impl.queue.TokenMonitoringResultHandler.getResults(TokenMonitoringResultHandler.java:27)
        at org.forgerock.openam.cts.CTSPersistentStoreImpl.update(CTSPersistentStoreImpl.java:131)
        at org.forgerock.openam.cts.CTSPersistentStoreImpl.update(CTSPersistentStoreImpl.java:124)
        at org.forgerock.openam.session.service.access.persistence.SessionPersistenceStore.save(SessionPersistenceStore.java:121)
        at org.forgerock.openam.session.service.access.persistence.InternalSessionPersistenceStore.store(InternalSessionPersistenceStore.java:61)
        at org.forgerock.openam.session.service.access.persistence.InternalSessionStoreChain$ChainIterator.store(InternalSessionStoreChain.java:99)
        at org.forgerock.openam.session.service.access.persistence.SessionPersistenceManagerStep.store(SessionPersistenceManagerStep.java:60)
        at org.forgerock.openam.session.service.access.persistence.InternalSessionStoreChain$ChainIterator.store(InternalSessionStoreChain.java:97)
        at org.forgerock.openam.session.service.access.persistence.caching.InMemoryInternalSessionCacheStep.store(InMemoryInternalSessionCacheStep.java:125)
        at org.forgerock.openam.session.service.access.persistence.InternalSessionStoreChain$ChainIterator.store(InternalSessionStoreChain.java:97)
        at org.forgerock.openam.session.service.access.persistence.AbstractInternalSessionStoreStep.store(AbstractInternalSessionStoreStep.java:46)
        at org.forgerock.openam.session.service.access.persistence.InternalSessionStoreChain$ChainIterator.store(InternalSessionStoreChain.java:97)
        at org.forgerock.openam.session.service.access.persistence.InternalSessionStoreChain.store(InternalSessionStoreChain.java:55)
        at org.forgerock.openam.session.service.access.persistence.SessionPersistenceManagerStep.notifyUpdate(SessionPersistenceManagerStep.java:74)
        at com.iplanet.dpro.session.service.InternalSession.notifyPersistenceManager(InternalSession.java:1112)
        at com.iplanet.dpro.session.service.InternalSession.setLatestAccessTime(InternalSession.java:830)
        at com.iplanet.dpro.session.operations.strategies.LocalOperations.getSessionInfo(LocalOperations.java:197)
        at com.iplanet.dpro.session.operations.strategies.LocalOperations.refresh(LocalOperations.java:112)
        at com.iplanet.dpro.session.monitoring.MonitoredOperations.refresh(MonitoredOperations.java:67)
        at com.iplanet.dpro.session.Session.doRefresh(Session.java:763)
        at com.iplanet.dpro.session.Session.access$000(Session.java:84)
        at com.iplanet.dpro.session.Session$1.run(Session.java:739)
        at com.sun.identity.session.util.RestrictedTokenContext.doUsing(RestrictedTokenContext.java:81)
        at com.iplanet.dpro.session.Session.refresh(Session.java:736)
        at org.forgerock.openam.session.SessionCache.getSession(SessionCache.java:253)
        at org.forgerock.openam.session.SessionCache.getSession(SessionCache.java:203)
        at org.forgerock.openam.session.SessionCache.getSession(SessionCache.java:188)
        at com.iplanet.sso.providers.dpro.SSOProviderImpl.destroyToken(SSOProviderImpl.java:343)
        at com.iplanet.sso.SSOTokenManager.destroyToken(SSOTokenManager.java:490)
        at com.sun.identity.security.AdminTokenAction.resetInstance(AdminTokenAction.java:182)
        at com.sun.identity.security.AdminTokenAction.reset(AdminTokenAction.java:176)
        at com.sun.identity.security.AdminTokenAction$1.shutdown(AdminTokenAction.java:131)
        at com.sun.identity.common.ShutdownManager.shutdown(ShutdownManager.java:218)
        at com.sun.identity.common.ShutdownServletContextListener.contextDestroyed(ShutdownServletContextListener.java:51)
        at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:4812)
        at org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5463)
        - locked <0x00000000803f1ce8> (a org.apache.catalina.core.StandardContext)
        at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257)
        - locked <0x00000000803f1ce8> (a org.apache.catalina.core.StandardContext)
        at org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1409)
        at org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1398)
        at java.util.concurrent.FutureTask.run([email protected]/FutureTask.java:264)
        at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
        at java.util.concurrent.AbstractExecutorService.submit([email protected]/AbstractExecutorService.java:145)
        at org.apache.catalina.core.ContainerBase.stopInternal(ContainerBase.java:983)
        - locked <0x00000000800d8040> (a org.apache.catalina.core.StandardHost)
        at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257)
        - locked <0x00000000800d8040> (a org.apache.catalina.core.StandardHost)
        at org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1409)
        at org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1398)
        at java.util.concurrent.FutureTask.run([email protected]/FutureTask.java:264)
        at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
        at java.util.concurrent.AbstractExecutorService.submit([email protected]/AbstractExecutorService.java:145)
        at org.apache.catalina.core.ContainerBase.stopInternal(ContainerBase.java:983)
        - locked <0x00000000800d7ee8> (a org.apache.catalina.core.StandardEngine)
        at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257)
        - locked <0x00000000800d7ee8> (a org.apache.catalina.core.StandardEngine)
        at org.apache.catalina.core.StandardService.stopInternal(StandardService.java:495)
        - locked <0x00000000800d7ee8> (a org.apache.catalina.core.StandardEngine)
        at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257)
        - locked <0x00000000800c57f8> (a org.apache.catalina.core.StandardService)
        at org.apache.catalina.core.StandardServer.stopInternal(StandardServer.java:982)
        at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257)
        - locked <0x00000000801b0250> (a org.apache.catalina.core.StandardServer)
        at org.apache.catalina.startup.Catalina.stop(Catalina.java:849)
        at org.apache.catalina.startup.Catalina$CatalinaShutdownHook.run(Catalina.java:996)

I have not invested any time in investigating the root cause yet.

At the moment, docker has no emulation for aarch64 architecture running Apple Silicon chips.
When i try to run Wren:AM via docker, build fails.

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M7:test (default-test) on project openam-installtools: There are test failures.

[ERROR] com.sun.identity.install.tools.util.OSCheckerTest.testArchitecture Time elapsed: 0.005 s <<< FAILURE! #12 175.6 java.lang.AssertionError: Expected aarch64 to be one of [i386, i686, x86, x86_64, amd64, PowerPC, ppc, ppc64, sparc] expected [1] but found [0]

As discussed in #24 the openam-ui-ria project pulls in an NPM installer via a Maven plugin. We need a way to verify the NPM installer we downloaded.

This might require adding functionality to the com.github.eirslett:frontend-maven-plugin plugin. NPM provides a list with hashes of the installers (SHASUMS256.txt) and has also signed this list (SHASUMS256.txt.asc).

When using external config repo, no changes are audited inside configuration audit log. This is because SMSLdapObject does not contain auditing logic as oposed to SMSEmbeddedLdapObject.

This issue was reported in FR's bugster as OPENAM-10562. Obvious fix is to port the functionality directly from SMSEmbeddedLdapObject, however that will break ssoadm setup as that is using SMSLdapObject without audit module (reported as OPENAM-11056). Any potential fix must be aware of this.

Somewhat related to #26. openam-ui-ria also manually pulls in PhantomJS with the frontend-maven-plugin plugin. Need to look in to how we can verify this download and possible mirror it.

To mirror it I already looked in to https://jfrog.com/knowledge-base/how-to-install-phantomjs-prebuilt/ which talks about using a generic mirror. I glanced over the settings in the Maven plugin but can't really see how to pin the version of PhantomJS it wants to download. Therefor it would be easier if we could use a generic remote repo since that automatically mirrors the remote site. The bug which the knowledge base article references is closed. However a quick test didn't work for me.

Since we share a common heritage with OpenAM the issue described here as "Issue #201801-12: Content Spoofing Vulnerability" probably affects wren:AM too.

We need to evaluate if and how this issue affects wren:AM and fix it.

Since we share a common heritage with OpenAM the issue described here as "Issue #201801-11: Business Logic Vulnerability" probably affects wren:AM too.

We need to evaluate if and how this issue affects wren:AM and fix it.

I propose to get rid of Apache Cargo Maven plugin. This plugin is used to merge WAR based modules openam-server-only and openam-console into openam-server. Due to that openam-server has uberwar as it's packaging definition, which makes extending that project somewhat hard.

Merging WAR modules can be achieved via Maven's WAR plugin overlay feature. The only thing this plugin is not capable of is merging web.xml. So to overcome that maybe we also can migrate to web-fragment.xml.

Benefits:

• Getting rid of unnecessary Maven Plugin.
• Having standard packaging type for the Maven project (instead of uberwar).
• Better support in some IDE (e.g. m2e)

Current default format for debug log filenames is something like service-mm.dd.yyyy-h.mm.ss.sss. I think we should change this default to something more sensible (e.g. something that correctly sorts by filename). Leaving this issue here so that it might get picked up eventually.

Errors messages on login pages are not localized.

Steps to reproduce:

1. Install Wren:AM
2. Open login form using browser with German (de_DE) as primary locale. Any other non-English locale supported by Wren:AM can be used too.
3. Submit invalid credentials.
4. An English message "Authentication Failed" will appear.

Expected result:

At least common error messages on login page are localized.

Since we share a common heritage with OpenAM the issue described here as "Issue #201801-05: Business Logic Vulnerability" probably affects wren:AM too.

We need to evaluate if and how this issue affects wren:AM and fix it.

Seems like the current way to manipulate internal AM policies within the sunamhiddenrealmdelegationservicepermissions realm is through LDAP. Would be nice if those policies can be viewed and updated through REST API.

Internal policies are kind of special because they have no application and resourceType assigned. Doing GET /openam/json/sunamhiddenrealmdelegationservicepermissions/policies?_queryFilter=true leads to NullPointerException caused by some missing resource type. So I am not sure if the requested feature is easily achievable.

Since we share a common heritage with OpenAM the issue described here as "Issue #201801-08: Business Logic Vulnerability" probably affects wren:AM too.

We need to evaluate if and how this issue affects wren:AM and fix it.

We want to switch to org.wrensecurity.wrenam groupId and cleanup POM files from obsolete stuff.

• I would like to order up POM files (e.g. by following https://maven.apache.org/developers/conventions/code.html#pom-code-convention)
• A lot of stuff can be removed after switching to the new JE backend (check Kortanul@4970bed655 for inspiration)
• We can drop everything that is pre Java 8 and Maven 3+

I don't necesarily want to do any dependency upgrades under this issue. That is a task for another day.

There are commented jaxb2-maven-plugins like in openam-saml2-schema module:

And the repository contains generated code. E.g.:

The goals of this issue are:

• verify and evaluate possibility of dropping the generated code
• upgrade JAXB (and drop JAXB1)

Since we share a common heritage with OpenAM the issue described here as "Issue #201801-01: Business Logic Vulnerability" probably affects wren:AM too.

We need to evaluate if and how this issue affects wren:AM and fix it.

The issue in the referenced document describes it is possible to access another resource owners access token by sending a specific type of request.

The document proposes not to use the JWT bearer token grant type as workaround

Evaluate and fix issue known to OpenAM as #201801-02

Since we share a common heritage with OpenAM the issue described here as "Issue #201801-02: Configuration password stored in plain text" probably affects wren:AM too.

We need to evaluate if and how this issue affects wren:AM and fix it.

The issue in the referenced document describes the export of server settings contain some configuration passwords in plain text.

The document indicates there is no workaround.

Adding of custom JVM options for ssoadm is not straightforward at the moment. User has to manually edit executable file (e.g. https://github.com/WrenSecurity/wrenam/blob/main/openam-federation/OpenFM/src/main/scripts/bin/ssoadm.bat#L46).

It would be nice to allow specifying of ssoadm JVM options using environment variables or setenv.bat|sh concept (Apache Tomcat). Any of these options would be better than manually editing the executable file.

The Wren logo is visibly blurred on 4K displays. Especially compared to other icons, font and inputs. I would like to suggest using vector graphic for logos.

I've fixed it adding -Duser.language=en -Duser.region=US to the argLine parameters of the Surefire plugin, under the main pom.xml:

<!-- Surefire Argument Line -->
<java.surefire.options>-Duser.language=en -Duser.region=US -Xms256m -Xmx256m -XX:MaxPermSize=96m</java.surefire.options>

My build environment is Windows 10, Cmder with Bash (MINGW32), Oracle JDK 1.8.0_144 and Maven 3.5.0.

Amster was a new CLI tool that was supposed to replace SSOAdministrationTool. This tool was never open-sourced and it is not part of our codebase. Hence the authentication module is kind of useless and we can (should) remove it (also the module does not contain any code).

Since we share a common heritage with OpenAM the issue described here as "Issue #201801-04: Open Redirect" probably affects wren:AM too.

We need to evaluate if and how this issue affects wren:AM and fix it.

There is a connection leak here - https://github.com/WrenSecurity/wrenam/blob/sustaining/13.5/openam-core/src/main/java/com/sun/identity/sm/ldap/SMSLdapObject.java#L624

When any component makes invalid search request (e.g. with non-existing base DN), the connection is never closed (returned to the pool). The whole SMSLdapObject looks full of similar corner cases, however this one happens quite often when updating policies.

org.restlet.jee Artifacts used to be available in the maven.forgerock.org repo but are no longer publicly availabe:

[ERROR] Failed to execute goal on project openam-http-client: Could not resolve dependencies for project org.forgerock.openam:openam-http-client:jar:13.5.1-SNAPSHOT: Failed to collect dependencies at org.restlet.jee:org.restlet:jar:2.3.4: Failed to read artifact descriptor for org.restlet.jee:org.restlet:jar:2.3.4: Could not transfer artifact org.restlet.jee:org.restlet:pom:2.3.4 from/to forgerock-staging-repository (http://maven.forgerock.org/repo/releases): Not authorized , ReasonPhrase:Unauthorized. -> [Help 1]

Since we share a common heritage with OpenAM the issue described here as "Issue #201801-09: Business Logic Vulnerability" probably affects wren:AM too.

We need to evaluate if and how this issue affects wren:AM and fix it.

While in the normal Maven build no ForgeRock repository is referenced anymore there is a Maven plugin in the openam-ui-ria module which uses NPM. This plugin instructs NPM to download artifacts from the ForgeRock repository (see config below). We need to inventory what it does and make modifications so it no longer needs the ForgeRock repository to build.

            <plugin>
                <groupId>com.github.eirslett</groupId>
                <artifactId>frontend-maven-plugin</artifactId>
                <version>0.0.28</version>
                <configuration>
                    <installDirectory>${node.install.directory}</installDirectory>
                </configuration>
                <executions>
                    <execution>
                        <id>install-node-and-npm</id>
                        <goals>
                            <goal>install-node-and-npm</goal>
                        </goals>
                        <phase>initialize</phase>
                        <configuration>
                            <nodeVersion>v4.4.5</nodeVersion>
                            <npmVersion>3.9.3</npmVersion>
                            <downloadRoot>http://maven.forgerock.org/repo/forgerock-third-party-virtual/</downloadRoot>
                            <npmDownloadRoot>http://maven.forgerock.org/repo/api/npm/npm-virtual/npm/-/</npmDownloadRoot>
                        </configuration>
                    </execution>
                    <execution>
                        <id>npm-install</id>
                        <goals>
                            <goal>npm</goal>
                        </goals>
                        <phase>initialize</phase>
                        <configuration>
                            <arguments>install</arguments>
                            <environmentVariables>
                                <PHANTOMJS_CDNURL>http://maven.forgerock.org/repo/forgerock-third-party-virtual</PHANTOMJS_CDNURL>
                            </environmentVariables>
                        </configuration>
                    </execution>
                    <execution>
                        <id>npm-build</id>
                        <goals>
                            <goal>npm</goal>
                        </goals>
                        <phase>compile</phase>
                        <configuration>
                            <arguments>run build:production -- --target-version=${project.version}</arguments>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

When creating custom authentication module with the same name as the module name via ssoadm, the configuration is stored in organization's default service entry.

However when XUI makes request for module instance configuration, it always goes for subschema configuration (unless the module is from a predefined set of auto-created modules)

When creating custom module instance from XUI, it automatically creates subschema config that inherits organization configuration. So XUI is consistent in this sense and the issue is probably in ssoadm.

FR references:

• https://bugster.forgerock.org/jira/browse/OPENAM-6676
• https://bugster.forgerock.org/jira/browse/OPENAM-9993

I was not able to properly deploy M1 release duo to errors in JavaDoc and due to some invalid configuration in Client SDK module.

Failed to execute goal org.apache.maven.plugins:maven-jar-plugin:3.3.0:jar (default-jar) on project openam-clientsdk: You have to use a classifier to attach supplemental artifacts to the project instead of replacing them.

To resolve this issue two things have to happen:

• mvn javadoc:javadoc has to run without any error
• there has to be no duplicate artifacts attached as can be seen in the error above

We need to drop CCPL content as it has No Derivatives attribute. This is mainly about top-level site content.

Based on gitter question:

URL based policy for *://*:*/*?* is not able to match queries containing question mark (e.g. http://example.com/foo?bar?baz), which are a valid URL.

I was able to debug policy evaluation up to SimpleReferenceTree#searchTree which is responsible for resource pattern matching. However as I am not that familiar with policy / privilege internals, I am not able to provide an easy solution or workaround (maybe such behaviour is expected?). This needs a little bit more attention than I am able to give right now.

In order for modifications made to the Supported Claims and Supported Scopes in an OAuth2 Provider (service) to become effective a server restart is required. Other options like the Enable "claims_parameter_supported" do become effective immediately without a server restart.

While researching this behavior I discovered this is a know issue in our common ancestor known as OPENAM-10584. According to this issue other settings in the OAuth2 Provider might (unconfirmed) also exhibit this (unwanted) behavior.

Since we share a common heritage with OpenAM the issue described here as "Issue #201801-07: Information Leakage" probably affects wren:AM too.

We need to evaluate if and how this issue affects wren:AM and fix it.

Creating realm via ssoadm ends with error. The realm itself is created but its not fully configured – there are missing Data Store, authentication modules…

$ ./ssoadm create-realm -u amAdmin -f /path/to/pwd.txt -e /foobar

Exception in thread "main" com.google.inject.ConfigurationException: Guice configuration errors:

1) No implementation for org.forgerock.openam.notifications.NotificationBroker annotated with interface org.forgerock.openam.notifications.LocalOnly was bound.
  while locating org.forgerock.openam.notifications.NotificationBroker annotated with interface org.forgerock.openam.notifications.LocalOnly

1 error
        at com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1004)
        at com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1009)
        at org.forgerock.guice.core.InjectorHolder.getInstance(InjectorHolder.java:97)
        at com.sun.identity.idm.plugins.internal.AgentsRepo.<init>(AgentsRepo.java:184)
        at com.sun.identity.sm.OrganizationConfigManager.createSubOrganization(OrganizationConfigManager.java:341)
        at com.sun.identity.cli.realm.CreateRealm.handleRequest(CreateRealm.java:86)
        at com.sun.identity.cli.SubCommand.execute(SubCommand.java:296)
        at com.sun.identity.cli.CLIRequest.process(CLIRequest.java:217)
        at com.sun.identity.cli.CLIRequest.process(CLIRequest.java:139)
        at com.sun.identity.cli.CommandManager.serviceRequestQueue(CommandManager.java:581)
        at com.sun.identity.cli.CommandManager.<init>(CommandManager.java:178)
        at com.sun.identity.cli.CommandManager.main(CommandManager.java:155)

Wren:AM 13.5 currently has a dependency on JAX-RPC 1.1.3_01-041406. The full name of the artifact is external:jaxrpc-impl:jar:1.1.3_01-041406. Judging from the external group name this appears to be a FR special release of the artifact. The 041406 is a tag in the JAX-RPC repo.

Wren:AM uses the normal corresponding API module (javax.xml:jaxrpc-api). It seems only the external:jaxrpc-impl:jar:1.1.3_01-041406 artifact needs to be deployed.

Just stumbled on inconsistency in LDAP authentication module.

The problem:

We support password policies that can limit number of uses for expired password (grace-login-count in Wren:DS, pwdGraceAuthnLimit in OpenLDAP, pwdGraceLoginLimit in IBM DS, ...).

The current authentication module is using one LDAP connection for the initial BIND request and a another LDAP connection for the password change. This means that we can send users to password change screen with already depleted authentication limit.

Possible solutions:

• We should investigate possibilities to workaround the limit imposed by password policies; i.e. is there some LDAP control that we can send to allow additional connection when changing the password (I doubt that, but you never know)?
• We should investigate possibility of sharing the same LDAP connection between the initial authentication request and the password change request (there can be more than one change request if the new password is rejected by the policy) . This needs a thorough consideration because such approach will take out one LDAP connection from connection pool for extended time period.
• We should simply document this behavior so that administrators can adjust LDAP configuration accordingly (i.e. set higher limit). We might want to update LDAP module so that it is able to recoginze the limit has been depleted when on "password change" screen.

we need help getting this project moving even faster. probably the best way to do this is to add contributing guidelines, per:
https://github.com/blog/1184-contributing-guidelines

there are some examples from Filip of Orchitech that need to be reviewed and incorporated: https://github.com/smolafilip/wrensec-website/wiki/Branching

in addition, the build instructions in the README file likely need updating as well.

The bintray repo has been sunset and its artifacts have been moved to Jfrog.

However, it is still being referenced by the build.

Error message:

[ERROR] Failed to execute goal on project openam-mib-schema: Could not resolve dependencies for project org.forgerock.openam:openam-mib-schema:jar:13.5.1-SNAPSHOT: Failed to collect dependencies at external:jdmkrt:jar:2007-01-10: Failed to read artifact descriptor for external:jdmkrt:jar:2007-01-10: Could not transfer artifact external:jdmkrt:pom:2007-01-10 from/to wrensecurity-forgerock-archive (http://dl.bintray.com/wrensecurity/forgerock-archive): Authorization failed for http://dl.bintray.com/wrensecurity/forgerock-archive/external/jdmkrt/2007-01-10/jdmkrt-2007-01-10.pom 403 Forbidden -> [Help 1]

We don't have source code for the org.forgerock.openam.pmd.rules:enforce-timeservice. Should be fairly straightforward to create that rule from scratch (I hope) as XPath rule. Until then we might disable PMD by default.

TimeService was introduced to allow customizable time source. So any direct call to stuff like Date constructor or System.currentTimeMillis is probably incorrect. Exact set of rules can be probably inferred from commits that introduced TimeService.

Setup of ssoadm utility does not work on Windows with JDK10+. The following error is thrown:

> setup.bat
0 was unexpected at this time.

Java version validation process in setup.bat expects that major version is 1 (see setup.bat#L51).

Since we share a common heritage with OpenAM the issue described here as "Issue #201801-10: LDAP Injection Vulnerability" probably affects wren:AM too.

We need to evaluate if and how this issue affects wren:AM and fix it.

When trying to suppress the OAUTH2 user consent page with the prompt=none as an argument with the Authorization Request AM still returns a interaction_required error. prompt=none is part of the OpenID Connect Core 1.0 standard.

This happens even when "Allow clients to skip consent" on the OAuth2 service is true and when the Implied consent option in the agent is also true.

A check of Wren:AM version does not work.

Following error is logged into amUpgrade debug log on every server start:

ERROR: Unable to parse date strings; current:Wren:AM 15.0.0-SNAPSHOT Build e395297f39 (2023-01-01T00:00:00Z) war version: Wren:AM 15.0.0-SNAPSHOT Build e395297f39 (2023-01-01T00:00:00Z)
java.text.ParseException: Unparseable date: "2023-01-01T00:00:00Z"
        at java.base/java.text.DateFormat.parse(DateFormat.java:399)
        at org.forgerock.openam.upgrade.VersionUtils.isVersionNewer(VersionUtils.java:88)
        at org.forgerock.openam.upgrade.VersionUtils.isVersionNewer(VersionUtils.java:68)
        at com.sun.identity.setup.AMSetupServlet.isCurrentConfigurationValid(AMSetupServlet.java:245)
        at com.sun.identity.setup.AMSetupServlet.registerListeners(AMSetupServlet.java:2069)
        at com.sun.identity.setup.AMSetupServlet.init(AMSetupServlet.java:209)

Related lines of code:

Since we share a common heritage with OpenAM the issue described here as "Issue #201801-03: Cross Site Scripting" probably affects wren:AM too.

We need to evaluate if and how this issue affects wren:AM and fix it.

Authentication chain update will not take effect until Wren:AM restart.

Steps to reproduce:

1. Run clean Wren:AM with default configuration
2. Create new authentication chain (e.g. "demo") in top level realm
3. Add modules "Data Store" and "HOTP" into that chain
4. Try login using this chain (http://.../auth?service=demo)
   • An user "demo" with password "changeit" can be used
   • User has to pass both auth. modules
5. Remove "HOTP" module from auth. chain
6. Try login using the chain again
   • User still has to pass both auth. modules

Expected behavior:

Changes in authentication chain will take effect immediately after save.

We should move SecurID support to a different repository. It is not buildable without an external proprietery JAR so it does not make sense to have it as implicit part of the product.

Overall we should be able to support modules / plugins like this. There are more examples like SecurID where we have additional features available but don't want to "pollute" the base project with them.

Since we share a common heritage with OpenAM the issue described here as "Issue #201801-06: Business Logic Vulnerability" probably affects wren:AM too.

We need to evaluate if and how this issue affects wren:AM and fix it.

Affected Versions

• 13.5.x (sustaining/13.5.x, at 772b7a7)

Summary

If you specify a custom class name for com.sun.identity.util.debug.provider when running Tomcat, and that class name is invalid, AM fails to start with an NPE instead of recovering gracefully.

Steps to Reproduce

1. Modify CATALINA_OPTS for AM to include the following:

   -Dcom.sun.identity.util.debug.provider=com.sun.identity.shared.debug.impl.StdOutDebugProvider
   

2. Ensure the AM WAR file is in the Tomcat webapps folder.
3. Attempt to launch Tomcat.

Expected Results

• The following error should appear in the Tomcat log:

  Failed to create debug service provider instance. Using the default provider.
  java.lang.ClassNotFoundException: com.sun.identity.shared.debug.impl.StdOutDebugProvider
        at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1364)
        at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1185)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:264)
  

• AM deploys and launches successfully.

Actual Results

• The following error appears:

  SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.startInternal One or more listeners failed to start. Full details will be found in the appropriate container log file
  SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.startInternal Context [/wrenam] startup failed due to previous errors
  INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/usr/local/tomcat/webapps/wrenam] has finished in [30,695] ms
  

• The following NPE appears in the Catalina logs:

   SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.listenerStart Exception sending context initialized event to listener instance of class [org.forgerock.guice.core.GuiceInitialisationFilter]
    org.forgerock.guava.common.util.concurrent.ExecutionError: java.lang.ExceptionInInitializerError
           at org.forgerock.guava.common.cache.LocalCache$Segment.get(LocalCache.java:2201)
           at org.forgerock.guava.common.cache.LocalCache.get(LocalCache.java:3937)
   Caused by: java.lang.ExceptionInInitializerError
           at com.sun.identity.shared.debug.Debug.initialize(Debug.java:292)
           at com.sun.identity.shared.debug.Debug.<clinit>(Debug.java:762)
           at org.forgerock.openam.slf4j.AMLoggerFactory$1.load(AMLoggerFactory.java:33)
           at org.forgerock.openam.slf4j.AMLoggerFactory$1.load(AMLoggerFactory.java:30)
   Caused by: java.lang.NullPointerException
           at com.sun.identity.shared.debug.Debug.getInstance(Debug.java:206)
           at com.sun.identity.shared.locale.Locale.<clinit>(Locale.java:84)
  

• AM fails to deploy and start.

Trying to build the Post Authentication plugin sample from ForgeRock (https://github.com/ForgeRock/openam-post-auth-sample) I receive this error:

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 8.404 s
[INFO] Finished at: 2018-01-11T19:10:56+01:00
[INFO] Final Memory: 15M/46M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project openam-post-auth-sample: Could not resolve dependencies for project org.forgerock.openam.examples:openam-post-auth-sample:jar:1.0.0-SNAPSHOT: Failed to collect dependencies at org.forgerock.openam:openam-core:jar:13.5.0-SNAPSHOT -> org.forgerock.commons:forgerock-bloomfilter-core:jar:1.0.1 -> org.forgerock.commons:forgerock-util:jar:3.0.1: Failed to read artifact descriptor for org.forgerock.commons:forgerock-util:jar:3.0.1: Could not transfer artifact org.forgerock.commons:forgerock-util:pom:3.0.1 from/to forgerock-private-releases (https://maven.forgerock.org/repo/private-releases): Not authorized , ReasonPhrase:Unauthorized. -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException

I noticed that I have in my .m2 repository the org.forgerock.commons:forgerock-util:jar:3.0.2 version, but not the required 3.0.1 version.
I built the main wrenam project successfully so I thought all the dependencies were installed in my local .m2 repository.

What I don't understand is how the org.forgerock.openam:openam-core:jar:13.5.0-SNAPSHOT was built if the org.forgerock.commons:forgerock-util:jar:3.0.1 was missing.

Maybe I should to instruct Maven to get only the local dependencies?

The version that we want to build and use is wrenam 13.5.x.
After built and deployed the wrenam app, If I try to click on button edit of "REALM" funciton, the wrenam not show the form.
The problem is on the openam-ui/openam-ui-ria project.
The pom was modified to switch on new repository, but the main.js file refers the old names.
Es: main.js --> "selectize" : "libs/selectize-non-standalone-0.12.1-min" - on the new repository (https://wrensecurity.jfrog.io/wrensecurity/releases/org/forgerock/commons/ui/libs/) the name is selectize.