[JBoss JIRA] (ELY-726) Default Mechanism Ordering Implementation
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-726?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-726:
---------------------------------
Fix Version/s: 1.1.0.CR2
(was: 1.1.0.CR1)
> Default Mechanism Ordering Implementation
> -----------------------------------------
>
> Key: ELY-726
> URL: https://issues.jboss.org/browse/ELY-726
> Project: WildFly Elytron
> Issue Type: Task
> Components: SASL
> Reporter: Darran Lofthouse
> Fix For: 1.1.0.CR2
>
>
> We have to have some form of mechanism ordering anyway to get silent mechanisms to the front of the queue.
> SaslMechanismInformation may need some updates but we have plenty of information about the mechanisms so we should be able to put together a reasonable documented ordering.
> Stronger mechanisms that can complete without interaction with the client can be pulled up the list as they can quickly silently fail where AuthenticationClient does not have enough information to handle them. This set probably includes JBOSS_LOCAL_USER, EXTERNAL, GSSAPI, GS2, and the token mechs.
> For username / password mechanisms we can ensure PLAIN goes last.
> Of the CRAM, Digest, and SCRAM set I would suggest first order by digest algorithm and then SCRAM -> Digest -> CRAM.
> There will be the opportunity for plenty of discussions on is X really better than Y but I think a reasonable default implementation that is documented will be much better than today's current random ordering. Once filtering has been applied to take into account things like available credentials in the realms etc.
> I would expect most lists to be very small, maybe some silent mechs a token mech and one or two username / password mechs depending on consistency of an identity store.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 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.CR2
(was: 1.1.0.CR1)
> 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.CR2
>
>
> 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, 10 months
[JBoss JIRA] (ELY-681) Hide private packages from generated javadoc.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-681?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-681:
---------------------------------
Fix Version/s: 1.1.0.CR2
(was: 1.1.0.CR1)
> Hide private packages from generated javadoc.
> ---------------------------------------------
>
> Key: ELY-681
> URL: https://issues.jboss.org/browse/ELY-681
> Project: WildFly Elytron
> Issue Type: Task
> Components: Build
> Reporter: Darran Lofthouse
> Priority: Critical
> Fix For: 1.1.0.CR2
>
>
> We may want two profiles so we can generate a full javadoc and a 'public' javadoc.
> The 'public' javadoc should be the default one generated and should exclude the following packages: -
> org.wildfly.security._private
> org.wildfly.security.asn1
> org.wildfly.security.auth.realm
> org.wildfly.security.auth.realm.*
> org.wildfly.security.authz.jacc
> org.wildfly.security.credential.store.impl
> org.wildfly.security.security.digest
> org.wildfly.security.http.impl
> org.wildfly.security.security.keystore
> org.wildfly.security.mechanism.oauth2
> org.wildfly.security.mechanism.scram
> org.wildfly.security.password.impl
> org.wildfly.security.password.util
> org.wildfly.security.pem
> org.wildfly.security.sasl
> org.wildfly.security.sasl.* (Except util)
> org.wildfly.security.util
> org.wildfly.security.util_private
> org.wildfly.security.x500
> org.wildfly.security.x500.cert
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ELY-873) AuthenticationClient testing without jboss-modules
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-873?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-873:
---------------------------------
Fix Version/s: 1.1.0.CR2
(was: 1.1.0.CR1)
> AuthenticationClient testing without jboss-modules
> --------------------------------------------------
>
> Key: ELY-873
> URL: https://issues.jboss.org/browse/ELY-873
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Authentication Client, Testsuite
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.1.0.CR2
>
>
> Keeping AuthenticationClient usable without a dependency on JBoss Modules is the kind of thing that will be easy to break.
> We should probably have a matrix of tests verifying AuthenticationClient anyway, we should then repeat the tests without JBoss Modules on the ClassPath.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months