Same issue occures in PicketLink Federation Subsystem for elements: role-generator, attribute-manager, handlers +++ This bug was initially created as a clone of Bug #1150639 +++ While configuring PicketLink IDM subsystem with CLI, there were found some problematic attributes, that causes conflicts. According to XSD schema: wildfly-picketlink-idm_1_0_xsd, these XML elements have attributes "code" and "class-name" which both defines their class name: supported-type, credential-handler, mapping These attributes can be used at the same time, which allows user to define different code and class-name. Consider the following CLI example: /subsystem=picketlink-identity-management/partition-manager=example/identity-configuration=test/jpa-store=jpa-store/supported-types=supported-types/supported-type=example:add(code=Role, class-name=org.picketlink.Group) which creates the following element in configuration: <supported-type class-name="org.picketlink.Group" code="Role"/> It is confusing whether Group or Role will be used. Would it be possible to use same approach as is used in security subsystem for login-modules via single "code" attribute? Therefore it would be consistent across server configuration. The existing "code" attribute is already able to work with type alias or FQN of a type, so that "class-name" is not needed. Furthermore while adding the listed elements with CLI, there can be added 2 or more elements with different names in path, but same values in attribute "code", which cannot be parsed after server reload. The code attribute should be validated that duplicates cannot be added. Similar validation is also in Federation subsystem for handlers of identity-provider. e.g CLI commands for adding supported-type with same code attribute: /subsystem=picketlink-identity-management/partition-manager=test/identity-configuration=example/jpa-store=jpa-store/supported-types=supported-types/supported-type=test1:add(code=User) /subsystem=picketlink-identity-management/partition-manager=test/identity-configuration=example/jpa-store=jpa-store/supported-types=supported-types/supported-type=test2:add(code=User)
Kabir Khan <kabir.khan> updated the status of jira EAP6-182 to Resolved
Kabir Khan <kabir.khan> updated the status of jira EAP6-182 to Reopened
https://github.com/jbossas/jboss-eap/pull/1810
Ondrej Lukas <olukas> updated the status of jira EAP6-182 to Reopened
Verification failed in EAP 6.4.0.DR6. Correctly fixed: - only one of code or class-name can be set - element with code attribute same as another element with same code attribute cannot be added - element with class-name attribute same as another element with same class-name attribute cannot be added But there are still no check when element with code attribute with the same value as another element with class-name with same attribute value is added. Consider running following CLI commands: /subsystem=picketlink-federation/federation=federation/identity-provider=idp/handler=a:add(code=SAML2IssuerTrustHandler) reload (because server is in reload-required state) /subsystem=picketlink-federation/federation=federation/identity-provider=idp/handler=b:add(class-name=SAML2IssuerTrustHandler) relaod -> failure If server is restarted after these commands it leads to Exception during server boot and server is not started. Also please fix documentation of code attribute in XSDs (wildfly-picketlink-federation_1_1.xsd, wildfly-picketlink-federation_1_0.xsd). Current implementation is not support FQN in code attribute.
https://github.com/jbossas/jboss-eap/pull/1838
Now, if you execute: /subsystem=picketlink-federation/federation=federation/identity-provider=idp/handler=a:add(code=SAML2IssuerTrustHandler) reload /subsystem=picketlink-federation/federation=federation/identity-provider=idp/handler=b:add(class-name=SAML2IssuerTrustHandler) reload You won't get an error. And this is still a valid configuration. The reason is that code resolves to a built-in class name. And class-name is a FQN, so it is different than the built-in type FQN. However, if you try to /subsystem=picketlink-federation/federation=federation/identity-provider=idp/handler=a:add(code=SAML2IssuerTrustHandler) reload /subsystem=picketlink-federation/federation=federation/identity-provider=idp/handler=b:add(class-name=org.picketlink.identity.federation.web.handlers.saml2.SAML2IssuerTrustHandler) reload it will fail. As you are trying to add a class-name with is the same as the built-in type referenced by the SAML2IssuerTrustHandler code/alias.
Verified in EAP 6.4.0.DR7.
Rostislav Svoboda <rsvoboda> updated the status of jira EAP6-182 to Resolved
Pedro Igor <pigor.craveiro> updated the status of jira WFLY-3978 to Resolved