Experience Delivers

Build brand, drive demand and extend your reach with web experience management

In Figure1, when a user gets successfully authenticated, it sends a user-id to CQ via HTTP header. [The syntax of this header can either be in the syntax defined for HTTP Basic Authentication, plain, or extractable by a Regular Expression]. Since the valid user has already been authenticated by the security solution, CQ is receiving the validated request as shown in figure. CQ assumes that the user has already been authenticated. CQ never sees the password or other credentials and would have no way of authenticating the user independently.

It is almost always ALSO necessary for a CRX user with the same ID to exist in the repository. If you are using LDAP, then the LDAP LoginModule can create users (and groups) on demand. The way this works is that, after receiving the validated request from Security Solution, CQ checks the existence of the user-id in the repository. If user doesn’t exist in the repository, then LDAP LoginModule gets the login request, and it populates the CRX user in the repository with information extracted from the LDAP server.

 If LDAP is not available, but some other user account storage system is, you can create a custom LoginModule to interface with that system to do the same thing.

Note: Access to CRX from any other means other than SecuritySolution should be blocked in HTTP Header Base Authentication. If not, then anyone can spoof the header and this would lead to security breach.

Configure Header Base Authentication in three steps:

Step 1:  Modify repository.xml file

• Open file repository.xml  under /crx-quickstart/repository/
• In LoginModule section , uncomment underline config :

<param name="trust_credentials_attribute" value="d5b9167e95dad6e7d3b5d6fa8df48af8"/ >

• Delete the old value of trust_credentials_attribute & provide a new value, for example, TrustedInfo.
• Save the repository.xml file and restart the CQ instance to pick the changes.

Step 2: Configure Adobe Granite SSO Authentication Handler:

• Log inside http://<CQ_instance>:<port_no.>/system/console/configMgr, and go to Adobe Granite SSO Authentication Handler & provide the different entries as shown below:-

a) Path: Path that this authentication handler will be used on. If this parameter is left empty the authentication handler is disabled.

b) Service Ranking: OSGi Framework Service Ranking value to indicate the order in which to call this service. This is an integer value where higher values designate higher precedence. Default value is 0.

c) Header Names: The name(s) of headers that might contain a user ID. In above example it is “uid”.

d) Format:

         1. Use Basic if the user ID is encoded with Base64 encoding.

         2. Use AsIs if the user ID is provided in plain text or any regular expression applied value should be used.

(i) Plain text example: If the user id is passed in header as a plain username, lets’ say John, then CRX will accept the user id John and authenticate the user. 

(ii) Regular expression example:  if you specify ^<DOMAIN>\\(.+)$ this will match against a header starting with <DOMAIN>\ and followed by the user ID (where <DOMAIN> is replaced by your own domain name). The user ID is then used as the value for SSO. If you need to use groups in your regular expression, you can specify the group by appending |<group-index> to the regular expression (the group index starts with 1). So the above example can be written as ^<DOMAIN>\\(.+)$|1.

• Trusted Credential Attribute: The name of the attribute (in the trusted credentials) that is set with the user information. In above config, its value is TrustedInfo.

Note: The value of Trusted Credential Attribute must be equal to the attribute you configure in repository.xml (<param name="trust_credentials_attribute" value="TrustedInfo"/>). This is the name of the Attribute used in the SimpleCredentials object to provide the userid from the SSOAuthenticationHandler to the authenticator CRXLoginModule. Therefore this has to be the same in the two configurations.

Step 3: Entry in Dispatcher.any file:

If organization is using Dispatcher to forward the requests to CQ instance, then do the following steps:

A.      Open Dispatcher.any file, & locate clientheaders section.

B.      Add HTTP header in the clientheaders list. In above example, it would be uid.

--------------------------------------------"Header Base Authentcation" configuration completes------------------------------------

To test the HTTP Header Base Authentication:

A. Configure an Apache instance in front of CQ to forward all request to the CQ instance.

B. Put a config line in “httpd.conf” of Apache :

RequestHeader set uid admin

Note: The above config will send header uid with value admin in every request. And admin is the default user available in CQ.

C. Restart the Apache Web Server to pick the changes.

D. Please make sure that Format in Adobe Granite SSO Authentication Handler should be AsIs.

E. Hit CQ via Apache, i.e.  http://<Apache>:80/libs/cq/core/content/welcome.html

F. As expected, user will log inside welcome page without providing credentials.