Missing support for ordering attributes on consent screen
Description
Environment
3.0.0 with LDAP and static connectors
is related to
Activity
Tom Zeller October 13, 2015 at 7:45 PM
Moved attribute ID comparator to system/ from conf/ in r7812.
http://svn.shibboleth.net/view/java-identity-provider?view=revision&revision=7812
Tom Zeller September 9, 2015 at 3:31 AM
Oh ! When I typed system/ I was thinking system/conf/profile-intercept-system.xml. But, yeah, I think you're right. I guess I was thinking that profile-intercept-system.xm was the system-space counterpart to user-space conf/consent-intercept-config.xml.
Scott Cantor September 9, 2015 at 1:36 AM
I'm probably missing an obvious reason this won't work, but...
The list its injecting is inside conf/intercept/consent-intercept-config.xml, which is included by the flow beans file where this comparator bean is being used.
Can't we just move DefaultAttributeIDComparator into system/flows/intercept/attribute-release-beans.xml outright? Is there a backward compatibility issue I'm overlooking?
I would also get rid of the alias, and just set p:attributeIdComparator in PopulateAttributeConsentContext to a conditional expression:
Tom Zeller July 1, 2015 at 1:57 AMEdited
Reopening due to last-minute change to the 3.1 branch.
Two issues :
r7608 was an incomplete merge of r7449
Both revisions introduce a non-API class into user-space config files.
The non-API bean definition :
needs to be injected with a list defined in user-space, so moving the bean definition to system/ will not work. Need to figure out a way when more time is at hand.
Tom Zeller June 30, 2015 at 4:21 PM
Just noting that I didn't think about locale-sensitive sorting of attribute IDs.
Hi,
In our IdPV2 deployments with uApprove, we have been setting the attribute order by whitelisting all attribute in the desired order.
We see this as critical for the user experience to group attributes together on the consent screen (e.g., commonName, displayName, givenName and surname are all together).
In IdPV3, there is no way to set the attribute order. The attributes appear in a "random" order - that does not change with a reload of the screen but does change if the set of attributes changes.
The rendering is done by a Velocity template (views/intercept/attribute-release.vm) that only iterates over the Map it receives.
The Map is a LinkedHashMap that should be preserving order. I tried digging through the code to see where it comes from, but could not find it.
I see one option for this as consistently using order-preserving Sets/Maps across the whole code, and then perhaps order could be determined by the order in which the attributes are listed in attribute-resolver.xml.
Alternatively, this is what I did as a workaround:
Add a new property to
conf/idp.properties
listing all defined attributes in the preferred order:And then modifying attribute-release.vm to use this property as the preferred order:
The code filters out attributes specified in the property but not in the current context, but does not render attributes that were not listed in the property.
I was trying to append the entries from consentableAttributes.keySet() that are not in the ordered list at the end, but my Velocity-fu is not good enough for that (totally new to Velocity and guessing on the syntax).
Would this be worth adding for the next release - some option of setting the attribute order?
Cheers,
Vlad