[JBoss JIRA] (ELY-1078) Elytron MatchRule.toString() method throws StringIndexOutOfBoundsException
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1078?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1078:
----------------------------------
Fix Version/s: 1.1.0.Beta49
(was: 1.1.0.Beta48)
> Elytron MatchRule.toString() method throws StringIndexOutOfBoundsException
> --------------------------------------------------------------------------
>
> Key: ELY-1078
> URL: https://issues.jboss.org/browse/ELY-1078
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta36
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 1.1.0.Beta49
>
>
> In case when implementation of {{asString(StringBuilder b)}} for MatchRule does not change length of passed parameter (which is 0) then 'java.lang.StringIndexOutOfBoundsException: String index out of range: -1' is thrown for calling {{MatchRule.toString()}} due to calling {{StringBuilder.setLength(-1)}}.
> e.g. MatchRule {{ALL}} in implementation {{asString(StringBuilder b)}} just returns passed parameter, which results to mentioned exception.
> Thrown exception:
> {code}
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> at java.lang.AbstractStringBuilder.setLength(AbstractStringBuilder.java:180)
> at java.lang.StringBuilder.setLength(StringBuilder.java:76)
> at org.wildfly.security.auth.client.MatchRule.toString(MatchRule.java:581)
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (ELY-715) SPNEGO: missing negstat field in the first reply
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-715?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-715:
---------------------------------
Fix Version/s: 1.1.0.Beta49
(was: 1.1.0.Beta48)
> SPNEGO: missing negstat field in the first reply
> ------------------------------------------------
>
> Key: ELY-715
> URL: https://issues.jboss.org/browse/ELY-715
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Mechanisms
> Reporter: Jan Kalina
> Assignee: Darran Lofthouse
> Fix For: 1.1.0.Beta49
>
>
> When the client sends an initial SPNEGO token with Kerberos as preferred mechanism and includes an invalid kerberos token, then client expects to see the {{WWW-Authenticate}} HTTP header with SPNEGO response {{negTokenResp[ negState = reject ]}}.
> As stated in [SPNEGO specification|https://tools.ietf.org/html/rfc4178#section-4.2.2] negstat is required in first reply:
> {code:borderStyle=dashed}
> negState
> ...
> This field is REQUIRED in the first reply from the target, and is
> OPTIONAL thereafter. When negState is absent, the actual state
> should be inferred from the state of the negotiated mechanism
> context.
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (ELY-1029) Support clients that provide an optional CallbackHandler
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1029?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1029:
----------------------------------
Fix Version/s: 1.1.0.Beta49
(was: 1.1.0.Beta48)
> Support clients that provide an optional CallbackHandler
> --------------------------------------------------------
>
> Key: ELY-1029
> URL: https://issues.jboss.org/browse/ELY-1029
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Authentication Client
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 1.1.0.Beta49
>
>
> Clients such as the WildFly CLI provide a CallbackHandler implementation in case it is needed and not as a sign that it must be used, i.e. the desired outcome is that if the information required can be obtained from the configuration then authentication proceeds without interaction with the end user.
> Neither the CLI or the end user should be required to be fully aware of the underlying security configuration.
> This is similar to web browser HTTP authentication where there is only an interaction with the user if actually required.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (ELY-1204) RealmIdentity should have a three-argument version of getCredential()
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1204?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1204:
----------------------------------
Fix Version/s: 1.1.0.Beta49
(was: 1.1.0.Beta48)
> RealmIdentity should have a three-argument version of getCredential()
> ---------------------------------------------------------------------
>
> Key: ELY-1204
> URL: https://issues.jboss.org/browse/ELY-1204
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Authentication Server, Realms
> Reporter: David Lloyd
> Fix For: 1.1.0.Beta49
>
>
> {quote}
> I observe that there is no method overload for {{RealmIdentity#getCredential()}} which accepts an {{AlgorithmParameterSpec}} as the {{CredentialSource}} types do. This theoretically limits the range of selectivity of credentials that can be used by a mechanism; though things like salt or nonce are usually derived from the stored credential rather than the other way around, it is possible that there are other parameters which might have an impact on the selection of the appropriate credential (like realm name, as I think this issue is about).
> An appropriate three-argument overload can be added to this interface as a {{default}} method. An additional {{applyToCredential}} method can also be added accordingly. An additional {{getCredentialAcquireSupport}} method should be added as well; though it could be {{default}}, the default implementation would be less than optimal as it would have to delegate to {{getCredential}} to function properly.
> It might be a good idea to add this overload now while the compatibility impact would be minimal; in this case, the new {{getCredentialAcquireSupport}} method would not have to be {{default}} (instead, the two-argument form could be made {{default}} or removed completely in favor of the three-argument version).
> {quote}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months