Bug 1151002

Summary:	Class-name/code attributes causes conflicts in PicketLink Federation subsystem
Product:	[JBoss] JBoss Enterprise Application Platform 6	Reporter:	Ondrej Lukas <olukas>
Component:	PicketLink	Assignee:	Pedro Igor <psilva>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Pavel Slavicek <pslavice>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	6.4.0	CC:	anmiller, bdawidow, kkhan, psilva
Target Milestone:	DR7
Target Release:	EAP 6.4.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	1150639	Environment:
Last Closed:	2019-08-19 12:42:18 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1150639
Bug Blocks:

Description Ondrej Lukas 2014-10-09 11:54:50 UTC

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)

Comment 1 JBoss JIRA Server 2014-10-14 13:01:27 UTC

Kabir Khan <kabir.khan> updated the status of jira EAP6-182 to Resolved

Comment 2 JBoss JIRA Server 2014-10-14 13:26:53 UTC

Kabir Khan <kabir.khan> updated the status of jira EAP6-182 to Reopened

Comment 3 Pedro Igor 2014-10-17 15:33:15 UTC

https://github.com/jbossas/jboss-eap/pull/1810

Comment 4 JBoss JIRA Server 2014-10-17 18:38:41 UTC

Kabir Khan <kabir.khan> updated the status of jira EAP6-182 to Resolved

Comment 5 JBoss JIRA Server 2014-10-22 09:08:12 UTC

Ondrej Lukas <olukas> updated the status of jira EAP6-182 to Reopened

Comment 6 Ondrej Lukas 2014-10-22 11:04:39 UTC

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.

Comment 7 Pedro Igor 2014-10-22 17:05:52 UTC

https://github.com/jbossas/jboss-eap/pull/1838

Comment 8 Pedro Igor 2014-10-22 17:09:00 UTC

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.

Comment 9 Ondrej Lukas 2014-11-03 07:55:05 UTC

Verified in EAP 6.4.0.DR7.

Comment 10 JBoss JIRA Server 2014-11-05 07:05:40 UTC

Rostislav Svoboda <rsvoboda> updated the status of jira EAP6-182 to Resolved

Comment 11 JBoss JIRA Server 2016-03-17 08:36:18 UTC

Pedro Igor <pigor.craveiro> updated the status of jira WFLY-3978 to Resolved