[jboss-jira] [JBoss JIRA] (ELY-698) Rework the constructor exclusion logic for authentication rules and configurations

[David Lloyd (JIRA)]

    [ https://issues.jboss.org/browse/ELY-698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313582#comment-13313582 ] 

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)