OSGi configuration deployed using package is not taking effect

Forum|Forum|5 years ago
May 19, 2020
8 replies
23907 views

SAML OSGi configuration (com.adobe.granite.auth.saml.SamlAuthenticationHandler.config) that is deployed using package (e.g. config.author, config.dev) is not taking effect. After each deployment, one needs to open the config manager, and just "save" the deployed configuration. Has anyone faced similar issues. Kindly share the resolution.

~~~~~~~~~~~~~~~~~~~~~~~~~ UPDATE ~~~~~~~~~~~~~~~~~~~~~~~~~~

@leoberliant , @sunjot16 , @user05162 , @briankasingli , @aemmarc2 greatly appreciate your leads. I thought, I would update you about what I have tried today. The issue is not resolved but I have some information on what appears to be resolving the issue. When the ui.apps package is deployed, I get these two entries in the error.log:

19.05.2020 16:51:15.225 *INFO* [JcrInstaller.1] org.apache.sling.installer.provider.jcr.impl.JcrInstaller Registering resource with OSGi installer: [InstallableResource, priority=200, id=/apps/cms-commons/config/com.client.cms.commons.service.impl.ProductSearchServiceImpl, InstallableResource, priority=200, id=/apps/cms-commons/config/org.apache.sling.commons.log.LogManager.factory.config-SAML, InstallableResource, priority=200, id=/apps/cms-commons/config/org.apache.sling.commons.log.LogManager.factory.config-cms-commons, InstallableResource, priority=200, id=/apps/cms-commons/config/com.client.cms.commons.service.impl.CMSCommonsConfigurationImpl, InstallableResource, priority=200, id=/apps/cms-commons/config/org.apache.sling.security.impl.ContentDispositionFilter.config, InstallableResource, priority=200, id=/apps/cms-commons/config/com.day.cq.commons.impl.ExternalizerImpl.config, InstallableResource, priority=200, id=/apps/cms-commons/config/com.client.cms.commons.service.impl.SiteSearchUrlConfigurationImpl, InstallableResource, priority=200, id=/apps/cms-commons/config/com.adobe.granite.auth.saml.SamlAuthenticationHandler.config, InstallableResource, priority=200, id=/apps/cms-commons/config/org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended-cms-commons, InstallableResource, priority=200, id=/apps/cms-commons/config/com.client.cms.commons.service.impl.TagRootPathServiceImpl, InstallableResource, priority=200, id=/apps/cms-commons/config/com.client.cms.commons.service.impl.APIConfigurationImpl]

19.05.2020 16:51:19.278 *INFO* [OsgiInstallerImpl] org.apache.sling.audit.osgi.installer Installed configuration com.adobe.granite.auth.saml.SamlAuthenticationHandler from resource TaskResource(url=jcrinstall:/apps/cms-commons/config/com.adobe.granite.auth.saml.SamlAuthenticationHandler.config, entity=config:com.adobe.granite.auth.saml.SamlAuthenticationHandler, state=INSTALL, attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:31:, service.pid=com.adobe.granite.auth.saml.SamlAuthenticationHandler], digest=a83b1f829c4410343b863230ebb7a9ed)

Clearly the JcrInstaller did it's job and installed the com.adobe.granite.auth.saml.SamlAuthenticationHandler

@user05162 , I checked the status in http://<host>:<port>/system/console/osgi-installer and it is INSTALLED

I opened up the configuration in the config manager, and just re-saved. No configuration was changed. With that I have this entry in the error.log

19.05.2020 16:52:12.172 *INFO* [JcrInstaller.1] org.apache.sling.installer.provider.jcr.impl.JcrInstaller Registering resource with OSGi installer: [InstallableResource, priority=200, id=/apps/cms-commons/config/com.adobe.granite.auth.saml.SamlAuthenticationHandler.config]

The SSO started working after this step of re-saving. So it seems that the JcrInstaller, when invoked the first time (by the package deployment) lacked something that required re-registering the resource with OSGi installer. I parsed the error.log for errors after first registering, I could not find any.

@leoberliant , I tried with both names: com.adobe.granite.auth.saml.SamlAuthenticationHandler-myname.config and without myname, the behavior listed above remained same. So that can be ruled out.

@sunjot16 , thanks for the lead. It seems the configuration being deployed is correct as the re-saving is all that I am doing to make things work. What are your thoughts?

@aemmarc2 , I am not able to find the config in the /apps/system/config after re-saving. Since it was not manually created or touched, it probably was not saved into the /apps/system/config

@briankasingli , I had previously created it manually but that was long back deleted. So at the time of deployment, the /apps/system/config did not have any com.adobe.granite.auth.saml.SamlAuthenticationHandler.config. Yeah, I can try with a blank AEM instance.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

A

aemmarc2

Adobe Employee

How deep is the path to the config? The JCR Installer (org.apache.sling.installer.provider.jcr.impl.JcrInstaller) by default only looks to a max depth of 4.

A

aemcq5Author

Hi aemmarc: my apologies, I probably did not understand the question. It seems that the JcrInstaller has been able to deploy the configuration successfully, as I can locate the deployed configuration in the config manager. The challenge is that the deployed SAML configuration does not take effect. Or in other words, after the deployment the navigating to the AEM https://myserver:4502/aem/start.html takes me to the AEM credentials page rather than authenticating me using the SSO. After I "just open the config, and save it", navigating to the link authenticates me on SSO. No login page is then shown. So seems like JcrInstaller did it's job but somehow the changes were not read by the AEM till I manually save the config

BrianKasingli

Community Advisor and Adobe Champion

@aemcq5,

This might be because the OSGI configuration not set in the correct place. Can you please share the location of where these configurations live? Starting with /apps/my-project/config/*?

A

aemcq5Author

The location does not seems to the issue as I am seeing the configuration is getting deployed to the right instance. Just that the configuration is not taking effect "unless I open the deployed configuration and save it manually". The path of the configuration is: /apps/<myproject>/config.prod.author/com.adobe.granite.auth.saml.SamlAuthenticationHandler.config.xml

U

user05162

Adobe Employee

The best way to know the root cause of this issue is to go to OSGI installer after you deploy the configuration and check the state of that config.

There might be conflict with other configurations Or the config file under crx-quickstart/launchpad/config/**** might not be owned by crx user.

[1] http://<host>:<port>/system/console/osgi-installer

sunjot16

Adobe Employee

It is recommended to create and maintain the configuration file by making actual changes in the web console.

The following doc may be helpful:

https://docs.adobe.com/content/help/en/experience-manager-64/deploying/configuring/configuring-osgi.html#osgi-configuration-with-configuration-files

Hope it helps !!

L

leoberliant

Adobe Employee

Make sure that your SAML configuration name includes a unique suffix:

com.adobe.granite.auth.saml.SamlAuthenticationHandler-myname.config

Vijayalakshmi_S

Hi @aemcq5,

Can you confirm the node name that you have used for the OSGI config node(sling:OsgiConfig) is in the format - "PID-uniqueidentifier"

In this case PID of SAML Authentication handler is com.adobe.granite.auth.saml.SamlAuthenticationHandler and not ~~com.adobe.granite.auth.saml.SamlAuthenticationHandler.config~~
Given that this is a factory config, we need to add an unique identifier (as we can have multiple instance for a factory config)
It should then be a node of
- name -> com.adobe.granite.auth.saml.SamlAuthenticationHandler-xyzidentifier
- type -> sling:OsgiConfig

Next steps:

Given that you have amended the config directly in web console, entry would be available in /apps/system/config. - You can delete the same
- Format of entry that is created this way will be "PID.autogeneratedcharacters.config" -> it is a node of type nt:file
  - Where autogeneratedcharacters is for identifying it as unique instance of factory config
- In case of normal OSGI service(not a factory), it will be of the format "PID.config" -> again a node of type nt:file
Create the config in above format(highlighted in green) and cross check in web console if an entry with identifier that you have created is available.
Note : Try this in your immediate lower environment, Can take back up of an entry from /apps/system/config from the respective environment before deleting.

A

aemcq5Author

Updated the question with further details

L

leoberliant

Adobe Employee

You need to make a correct SAML configuration package:

- use sling:OsgiConfig node

- name the node with unique PID /apps/cms-commons/config/com.adobe.granite.auth.saml.SamlAuthenticationHandler-mysaml

- add all required configuration as properties (logoutURL in my sample)

A

aemcq5Author

Thanks much @leoberliant: Yes, I am following all 3 points you have mentioned. My client's IDP does not offer logout, so "handleLogout=false" and "logoutUrl" is blank. There are quite a few other attributes, which are filled out correctly. What is baffling is that the "exactly same configuration" when re-saved makes the SSO redirection to "idpUrl" work

A

Abhilasha_S

Hi @aemcq5 , Did you found any solution to this?

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded