[OPENAM-3135] XUI does not support resource based authentication Created: 08/Oct/13  Updated: 20/Nov/16  Resolved: 02/Nov/15

Status: Resolved
Project: OpenAM
Component/s: rest, XUI
Affects Version/s: 11.0.0, 12.0.1, 13.0.0
Fix Version/s: 12.0.3, 13.0.0

Type: Task Priority: Major
Reporter: Peter Major [X] (Inactive) Assignee: Julian Kigwana [X] (Inactive)
Resolution: Fixed Votes: 0
Labels: 13.0.0-Must-Fix, AME, TESLA, release-notes
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
is related to OPENAM-7467 Redirect loop with XUI and resource=t... Resolved
Rank: 1|hzle9j:
Sprint: Sprint 97 - Team Tesla
Support Ticket IDs:
QA Assignee: Filip Kubáň [X] (Inactive)
Verified Version/s:


Currently it seems XUI does not support resource based authentication (used with the resource request parameter). We need to assess whether the resource based authentication needs to be implemented in XUI, and most likely the REST authentication interface will require some changes as well.

Comment by Nathalie Hoet [ 05/Oct/15 ]

I checked the Authentication REST endpoint (12.0.1 and 13-SNAPSHOT-20150930) and it supports resource-based authentication

Comment by Andy Hall [ 12/Oct/15 ]

There have been lots of changes in trunk in this area.
Would be great if you can try with a recent nightly build of AM13.

Comment by Nathalie Hoet [ 13/Oct/15 ]

Reproduced with OpenAM 13 - nightly from 30 Sept

Comment by Rich Riley [X] (Inactive) [ 21/Oct/15 ]

Could someone post the steps to reproduce / expected behaviour for this?

Comment by Nathalie Hoet [ 21/Oct/15 ]

Steps to reproduce:

  • Create a ldapchain with LDAP module set to REQUIRE (I also typically modify the text of the LDAP module to verify at first sight that I am in the LDAP one and not datastore module)
  • Leave default chain to ldapService
  • Create a policy:
    -> resource, e.g. http://website.example.com:80/index.html
    -> subject all authN Users
    -> Environment condition : authenticate to chain ldapchain

Expected behaviour: when accessing the following URL:


the ldapchain should be presented (LDAP module on screen), instead of the default ldapservice (DataStore module)

I usually check that is works with UI first, then turning XUI on, it fails.

Comment by Nathalie Hoet [ 29/Oct/15 ]

Extra information. The working REST call for resource-base authentication is:

curl --request POST "http://openam.example.com:18080/openam/json/authenticate?authIndexType=resource&authIndexValue=http%3A%2F%2Fwebsite.example.com%2Findex.html"
Comment by Neil Madden [ 29/Oct/15 ]

To support specifying the resource URL via the 'goto' parameter, the /json/authenticate endpoint would need to duplicate the logic in LoginViewBean#prepareLoginParams:

        } else if (((reqDataHash.get(ISAuthConstants.IP_RESOURCE_ENV_PARAM)
            != null) && "true".equalsIgnoreCase((String) reqDataHash.get(
                 ISAuthConstants.IP_RESOURCE_ENV_PARAM))) ||
            ((reqDataHash.get(ISAuthConstants.IP_RESOURCE_ENV_PARAM) == null) &&
              (reqDataHash.get(ISAuthConstants.RESOURCE_URL_PARAM) != null))) {
            indexType = AuthContext.IndexType.RESOURCE;
            indexName = AuthClientUtils.getResourceURL(request);
            envMap = AuthClientUtils.getEnvMap(request);

I.e., if the 'resource' parameter is just 'true' then we lookup the resource URL via AuthClientUtils.getResourceURL(request), which looks for either a 'resourceURL' or 'goto' parameter on the request.

Comment by Julian Kigwana [X] (Inactive) [ 29/Oct/15 ]

There is a small client side fix required, however the backend needs to be able to support this
which authenticates then redirects the browser to the goto url or resourceURL

Currently the backend support this
Which authenticates, but does not redirect.

Comment by Neil Madden [ 30/Oct/15 ]

Server-side issue fixed. Back to Julian for any remaining client-side work.

Comment by Filip Kubáň [X] (Inactive) [ 03/May/16 ]

verified on: OpenAM 12.0.3-RC2 Build 4dbe218a05 (2016-April-25 17:57)

Generated at Fri Mar 05 07:12:50 UTC 2021 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.