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 But there are still scenarios which allows invalid configuration: - element with code attribute same as another element with same code attribute can be added - element with class-name attribute same as another element with same class-name attribute can be added - element with code attribute value same as another element class-name attribute value can be added There should be check if same code/class-name is not already added to avoid duplicates, which leads to Exception after server restart. Consider running following CLI commands: /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) reload -> failure If server is restarted after these commands it leads to Exception during server boot and server is not started. There are 3 elements in IDM subsystem which are affected by this issue: supported-type, credential-handler, mapping Also please fix documentation of code attribute for these elements in XSD (wildfly-picketlink-idm_1_0.xsd). Current implementation does not support FQN in code attribute.
https://github.com/jbossas/jboss-eap/pull/1838
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