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 ~~~~~~~~~~~~~~~~~~~~~~~~~~
@berliant , @sunjot16 , @Jaideep_Brar , @BrianKasingli , @aemmarc 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
@Jaideep_Brar , 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.
@berliant , 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?
@aemmarc , 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.
Topics help categorize Community content and increase your ability to discover relevant content.
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.
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.
It is recommended to create and maintain the configuration file by making actual changes in the web console.
The following doc may be helpful:
Hope it helps !!
Make sure that your SAML configuration name includes a unique suffix:
Can you confirm the node name that you have used for the OSGI config node(sling:OsgiConfig) is in the format - "PID-uniqueidentifier"
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)
Hi @Abhilasha_S, I do not recall that any solution was found for this. I had ended up saving the manual instructions for the admin (on how to configure the SAML/SSO in a news instance). Addition of the SAML configuration, anyway, required manual steps like uploading the IDM cert and referencing that in the SAML OSGi configuration.
I managed to duplicate your issue myself. I found a configuration format that immediately turns IDP redirection:
Keep in mind, that after you deploy a package, you need to logout from AEM