[AMAGENTS-3331] 5.7 - WPA - AM Compatibility Created: 19/Mar/20  Updated: 22/Jun/20  Resolved: 22/Jun/20

Status: Closed
Project: OpenAM Agents
Component/s: Web Agents
Fix Version/s: None

Type: Story Priority: Blocker
Reporter: edwardb Assignee: Unassigned
Resolution: Done Votes: 0
Labels: CURIE
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Attachments: PNG File AM 7.0.0 WPA Failures.png    
Issue Links:
Relates
relates to OPENAM-15790 The /json/users endpoint no longer pr... Resolved
relates to OPENAM-16209 Parameters included in conditional lo... Closed
relates to OPENAM-16257 tokenid is not returned in session up... Closed
is related to AMAGENTS-1610 If we set a property in the Custom Pr... Closed
Sub-Tasks:
Key
 Summary
 Type
 Status
 Assignee
AMAGENTS-3457 Check that AM 7.0.0 works with Agent Technical task Closed edwardb  
AMAGENTS-3458 Check that AM 5.6.2.3 Works with Agent Technical task Closed edwardb  
AMAGENTS-3459 Check that AM 5.5.x works with Agent Technical task Closed Richard Hruza  
AMAGENTS-3460 Check what happens if we upgrade from... Technical task Closed edwardb  
Story Points: 3
Sprint: 2020.06 - Agents, 2020.07 - Agents, 2020.08 - Agents
Epic Link: 5.7 QA

 Description   

This task is to check that the agent is compatible with different versions of AM.

As a minimum we need to run the functional tests against the latest sustaining AM release and the AM which is in Master. (note that Maxwell run the agent tests against master but that they use an earlier version of the agent-tests).

In addition we need to check with AM team that there are no features which present a high risk for the Agent. An example which may need to be considered is the file based config since we have not tried creating a profile using this and checking that it works. As an aside it should be noted that file based config is being considered as a means of running perf tests against the agent.

 Comments   
Comment by edwardb [ 01/Apr/20 ]

When Running against AM 7.0.0 Nightly (on 1st April) It seemed that basic functionality for policy does not work.

To recreate:

Set up a policy like Policy.createBuilder()
.name(this.getMethodName())
.resources(Collections.singleton(agentConfig.getAgentProto() + "://:/*"))
.realm(Realm.root())
.subject(Subject.getSubjectAuthenticatedUsers())
.policySet(ResourceType.urlResourceType(server), PolicySet.defaultPolicySet())
.create();

Try to access any resource

Expected result

Access allowed

Actual result

Get directed to http://agent.localtest.me/agent/cdsso-oauth2 with forbidden

Comment by edwardb [ 01/Apr/20 ]

It is likely that this issue is related to OPENAM-15790

Comment by edwardb [ 30/Apr/20 ]

Running Tests locally using AM 7.0.0 From April 28th we get 17 failures

Comment by edwardb [ 04/May/20 ]

Note that when we make change so that the urls are validated in AM then we get CustomLoginAllowAccessAmDomain and CustomLoginWithPostDataPreservation

Comment by edwardb [ 06/May/20 ]

Testing against M8 of the agent we get 7 failures. 2 of them still need to be investigated.
1) publicAmUrlForCDSSOInRealm

This fails because by default the property com.sun.identity.agents.config.fqdn.check.enable is set to true in AM 7.0.0 whereas in earlier versions of AM it is set false. Is this correct or should we change in AM 7.0.0?

2) CustomLoginUsingSpecifiedUserRealmAmDomain

This was failing because we need to use the validation service in the specific realm

3) loginWithRealmSetByCustomLoginPage

This fails because PAP properties are added to the jwt - this is essentially an AM issue

4)CustomLoginAllowsAccessAgentDomain

This fails because PAP properties are added to the jwt - this is essentially an AM issue

5) ConditionalLoginWithCustomLoginAllowsAccess

This fails because PAP properties are added to the jwt - this is essentially an AM issue

6) CustomLoginAllowsAccessAmDomain

This was failing because validation service needs to be set for the root realm

7) CustomLoginWithPostDataPreservation

This was failing because validation service needs to be set for the root realm

This accounts for all of the issues we see with AM 7.0.0

Comment by edwardb [ 19/May/20 ]

Notes for the Agent Compatibility

1a) http://abondance-fr.internal.forgerock.com/pkg/servers/forgerock/Agent/web-agent/staging/5.7.0-M8/web-agent-5.7.0-M8-Apache_v24_Linux_64bit.zip with AM6.5.2.3

All tests pass

1b) After upgrading AM to AM 7.0.0 (note this is using the AM snapshot for 19th May) there is one error

com.forgerock.openam.functionaltest.amagenttests.universal.TestAgentCustomLogin.TestAgentCustomLogin upgradeSessionWithCustomLoginPage

This is due to https://bugster.forgerock.org/jira/browse/OPENAM-162572) https://ci.forgerock.org/view/OpenAM/job/OpenAM-QA/job/AgentTests/job/Docker_c_agent_tests/436/

http://abondance-uk.internal.forgerock.com/pkg/servers/forgerock/Agent/web-agent/staging/5.7.0-M9/web-agent-5.7.0-M9-Apache_v24_Linux_64bit.zip
http://abondance.internal.forgerock.com/pkg/servers/forgerock/OpenAM/staging/6.0.0.7/AM-6.0.0.7.war

All tests pass

3) https://ci.forgerock.org/view/OpenAM/job/OpenAM-QA/job/AgentTests/job/Docker_c_agent_tests/437/

http://abondance-uk.internal.forgerock.com/pkg/servers/forgerock/Agent/web-agent/staging/5.7.0-M9/web-agent-5.7.0-M9-Apache_v24_Linux_64bit.zip

http://abondance.internal.forgerock.com/pkg/servers/forgerock/OpenAM/staging/6.5.0.1/AM-6.5.0.1.war

All tests pass

Comment by edwardb [ 20/May/20 ]

There is an AM issue which needs to be dealt with but this can now be closed.

Generated at Sun Jan 24 18:41:24 UTC 2021 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.