[
https://issues.jboss.org/browse/ELY-698?page=com.atlassian.jira.plugin.sy...
]
David Lloyd commented on ELY-698:
---------------------------------
The present requirements for an AuthenticationConfiguration are:
* Ordering is insignificant for non-overlapping configurations. For example, if A then B
are added into a configuration, and A and B do not logically overlap, the result will be
identical to adding B then A.
* Equals/hashCode must respect the ordering rule. In the previous example, both
configurations must have the same hash code and be equal to one another.
* In order to meet this rule, two logically overlapping configurations may not coexist on
a configuration. For example, two different configurations that both logically establish
a cleartext password will be exclusive, such that whichever one is added last is retained
and the other one is dropped.
I suppose these rules really should be on the JavaDoc.
Rework the constructor exclusion logic for authentication rules and
configurations
----------------------------------------------------------------------------------
Key: ELY-698
URL:
https://issues.jboss.org/browse/ELY-698
Project: WildFly Elytron
Issue Type: Task
Components: Authentication Client
Reporter: David Lloyd
Priority: Minor
The current authentication rule and configuration classes are designed to ensure that
mutually incompatible rules and configurations cannot coexist. However the implementation
is applied a bit erratically. There may be problems with commutatively applying checks.
Some checks may be missing or extraneous.
We need a new approach where the mutual exclusion set is somehow enforced centrally. One
option is to have literal sets, and each class that is a member of one or more sets must
remove all other handlers that are also within the set(s). A predicate could be used to
make this efficient by only sweeping the list one time, in contrast to the current
mechanism which sweeps the list once per exclusive type.
Another option is to have a marker interface for each capability, and to remove all peers
with the same capability. A predicate can also be used in this case.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)