[JBoss JIRA] (ELY-1653) JDK 11 Support
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1653?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1653:
----------------------------------
Fix Version/s: 1.7.0.CR3
(was: 1.7.0.CR2)
> JDK 11 Support
> --------------
>
> Key: ELY-1653
> URL: https://issues.jboss.org/browse/ELY-1653
> Project: WildFly Elytron
> Issue Type: Task
> Components: Build
> Reporter: Darran Lofthouse
> Assignee: Justin Cook
> Fix For: 1.7.0.CR3
>
>
> I suspect this will likely take three / four steps: -
> # Convert he project to a multi-release built using Java 9
> # Eliminate the use of APIs in sun.misc and sun.reflect in the Java 9 variant
> # Ensure the project can be build on JDK 11
> This final step may not be achievable in the short term until we can drop support for JDK 8 but by moving to the Java 9 MR jar our jar should be compatible on Java 10 and 11 as well. We may want to define a PR run that builds on Java 9 but tests in Java 11, this would mean the testsuite at least needs to be buildable on Java 11.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (ELY-1525) When SSO is enabled, multipart form and form enconding stop working.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1525?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1525:
----------------------------------
Fix Version/s: 1.7.0.CR3
(was: 1.7.0.CR2)
> When SSO is enabled, multipart form and form enconding stop working.
> --------------------------------------------------------------------
>
> Key: ELY-1525
> URL: https://issues.jboss.org/browse/ELY-1525
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.6.Final, 1.2.1.Final
> Reporter: Estevão Freitas
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 1.7.0.CR3
>
>
> I developed a JSF application with "h:inputFile" component and it requires a form with " enctype="multipart/form-data" ".
> I use this tutorial for SSO: https://docs.jboss.org/author/display/WFLY/Web+Single+Sign-On .
> When I execute the last step: " /subsystem=undertow/application-security-domain=other/setting=single-sign-on:add(key-store=example-keystore, key-alias=localhost, domain=localhost, credential-reference=clear-text=secret}) ", all commandButtons stop working.
> If I remove the "h:inputFile" component and " enctype="multipart/form-data" " from form all buttons works again, but all words with accents are corrupted.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (ELY-1475) Empty username for FormAuthenticationMechanism causes IllegalArgumentException
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1475?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1475:
----------------------------------
Fix Version/s: 1.7.0.CR3
(was: 1.7.0.CR2)
> Empty username for FormAuthenticationMechanism causes IllegalArgumentException
> ------------------------------------------------------------------------------
>
> Key: ELY-1475
> URL: https://issues.jboss.org/browse/ELY-1475
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.2.0.Beta11
> Reporter: Ondrej Lukas
> Assignee: Ilia Vassilev
> Fix For: 1.7.0.CR3
>
>
> In case when empty username is passed to FormAuthenticationMechanism.attemptAuthentication then IllegalArgumentException is thrown from constructor of NameCallback. This happens in cases when form is sent with empty value for j_username.
> See exception:
> {code}
> ERROR [io.undertow.request] (default task-18) UT005023: Exception handling request to /depForm/j_security_check: java.lang.IllegalArgumentException
> at javax.security.auth.callback.NameCallback.<init>(NameCallback.java:90)
> at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:60)
> at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptAuthentication(FormAuthenticationMechanism.java:172)
> at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:106)
> at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:114)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:115)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94)
> at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78)
> at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:100)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> It seems that [1] should also check {{username.length() == 0}}.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/32ff7c17965b3eca...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (ELY-1682) Fallback to another SASL client mechanism when SASL client initialisation fails
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1682?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1682:
----------------------------------
Fix Version/s: 1.7.0.CR3
(was: 1.7.0.CR2)
> Fallback to another SASL client mechanism when SASL client initialisation fails
> -------------------------------------------------------------------------------
>
> Key: ELY-1682
> URL: https://issues.jboss.org/browse/ELY-1682
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SASL
> Affects Versions: 1.7.0.CR1
> Reporter: Martin Choma
> Fix For: 1.7.0.CR3
>
> Attachments: org.jboss.eapqe.krbldap.eap71.tests.krb.ejb.KerberosEjbGssapiTestCase-output.txt
>
>
> {code:title=HipChat conversation}
> Martin Choma: I have got this situation here; Server is authenticated with GSSAPI and PLAIN. Client has only username/password credential - no kerberos credential.
> But client tries to create GssapiSaslClient as well (which make problem on IBM). Once I set .setSaslMechanismSelector(SaslMechanismSelector.fromString("PLAIN")) scenario works ok.
> I wonder could Authentication Client be smart enough to not try to initialize authentication mechanisms which it has not credentials for?
> Darran Lofthouse: Client side GSSAPI we tend not to have configured credentials as the mech obtains from OS level. The mech should fail and allow the next mech to be selected
> Martin Choma: Ok, so I will create issue. Seems on client side this mechanism fallback does not work properly. (At least in IBM JDK case).
> In this case it is initialization of mechanism which is failing, so maybe fallback does not have chance to get involved.
> Darran Lofthouse: Sounds possible, if a mech can not initialise we should likely treat it as a failed mech and move on - maybe something needed in Remoting
> though for that one as that is where that loop happens but start with an ELY issue
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (ELY-1680) IBM, failing KeyStoreSuiteChild.testGetCertificateChainBinary
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1680?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1680:
----------------------------------
Fix Version/s: 1.7.0.CR3
(was: 1.7.0.CR2)
> IBM, failing KeyStoreSuiteChild.testGetCertificateChainBinary
> -------------------------------------------------------------
>
> Key: ELY-1680
> URL: https://issues.jboss.org/browse/ELY-1680
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Testsuite
> Affects Versions: 1.6.1.Final
> Reporter: Martin Choma
> Fix For: 1.7.0.CR3
>
>
> {code}
> [ERROR] testGetCertificateChainBinary(org.wildfly.security.ldap.KeyStoreSuiteChild) Time elapsed: 0.057 s <<< FAILURE!
> org.junit.ComparisonFailure: expected:<CN=[firefly_binary], OU=Elytron, O=Elyt...> but was:<CN=[localhost], OU=Elytron, O=Elyt...>
> at org.wildfly.security.ldap.KeyStoreSuiteChild.testGetCertificateChainBinary(KeyStoreSuiteChild.java:136)
> at org.wildfly.security.ldap.DirContextFactoryRule$1.evaluate(DirContextFactoryRule.java:218)
> {code}
> If I switch order of certificates in chain, then test passes.
> {code}
> diff --git a/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java b/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> index d8095867a..cda635beb 100644
> --- a/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> +++ b/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> @@ -133,8 +133,8 @@ public class KeyStoreSuiteChild {
> Certificate[] chain = keyStore.getCertificateChain("firefly_binary");
> Assert.assertNotNull(chain);
> Assert.assertEquals(2, chain.length);
> - Assert.assertEquals("CN=firefly_binary, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[0]).getSubjectDN().toString());
> - Assert.assertEquals("CN=localhost, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[1]).getSubjectDN().toString());
> + Assert.assertEquals("CN=firefly_binary, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[1]).getSubjectDN().toString());
> + Assert.assertEquals("CN=localhost, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[0]).getSubjectDN().toString());
> }
> {code}
> -For some reason I want able to debug code with -Dmaven.surefire.debug (Breakpoint was never hit) to find out which calls switch the order.-
> It takes long (5min) for debugger to attach to code.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (ELY-1677) Elytron Bearer Token Authentication - Return a 401 on Invalid Token
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1677?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1677:
----------------------------------
Fix Version/s: 1.7.0.CR3
(was: 1.7.0.CR2)
> Elytron Bearer Token Authentication - Return a 401 on Invalid Token
> -------------------------------------------------------------------
>
> Key: ELY-1677
> URL: https://issues.jboss.org/browse/ELY-1677
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: Authentication Mechanisms
> Affects Versions: 1.7.0.CR1
> Reporter: Edward Stathopoulos
> Assignee: Darran Lofthouse
> Fix For: 1.7.0.CR3
>
>
> *Issue*
> Currently, Elytron will send back a 403 Response when an invalid bearer token is sent. For the built-in JWT validator (the token validation we are using), this [includes a few checks like signature, expiration time, audience and issuer|https://github.com/wildfly-security/wildfly-elytron/blob/1.7.0.CR1...].
> It seems that the current [BearerTokenAuthenticationMechanism|https://github.com/wildfly-security/wi...] does not differentiate between failed authentication and failed authorization, returning a 403 in both cases. This produces conflicting and erroneous results. Did I fail to authenticate (say, expired JWT) or did I authenticate but do not have access to the resource in question?
> This would also be closer in line with [RFC 6750 (The OAuth 2.0 Authorization Framework: Bearer Token Usage)|https://tools.ietf.org/html/rfc6750#section-3] which includes an example of an expired (invalid) token.
> {quote}
> And in response to a protected resource request with an
> authentication attempt using an expired access token:
> HTTP/1.1 401 Unauthorized
> WWW-Authenticate: Bearer realm="example",
> error="invalid_token",
> error_description="The access token expired"
> {quote}
> *Potential Solution*
> Perhaps this could be ameliorated by something akin to the following change in BearerTokenAuthenticationMechanism::evaluateRequest by differentiating between failure to authorize and failure to authenticate the token. Merely a quick, unvetted example as I haven't had enough time to dig in to the source.
> {code}
> if (verifyCallback.isVerified()) {
> AuthorizeCallback authorizeCallback = new AuthorizeCallback(null, null);
> handleCallback(authorizeCallback);
> if (authorizeCallback.isAuthorized()) {
> httpBearer.debugf("Token authentication successful.");
> handleCallback(new IdentityCredentialCallback(new BearerTokenCredential(tokenEvidence.getToken()), true));
> handleCallback(AuthenticationCompleteCallback.SUCCEEDED);
> request.authenticationComplete();
> return;
> }
> else{
> httpBearer.debugf("Token authorization failed message.");
> request.authenticationFailed("Some token unauthorized message", response -> response.setStatusCode(FORBIDDEN));
> return;
> }
> }
> httpBearer.debugf("Token authentication failed.");
> request.authenticationFailed("Invalid bearer token", response -> response.setStatusCode(UNAUTHORIZED));
> return;
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (ELY-1675) Merge roles from entry and entry attributes
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1675?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1675:
----------------------------------
Fix Version/s: 1.7.0.CR3
(was: 1.7.0.CR2)
> Merge roles from entry and entry attributes
> -------------------------------------------
>
> Key: ELY-1675
> URL: https://issues.jboss.org/browse/ELY-1675
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.7.0.CR1
> Reporter: Martin Choma
> Priority: Critical
> Fix For: 1.7.0.CR3
>
>
> Double check Elytron ldap realm is capable doing this:
> Having ldap entries like this
> {code}
> dn: cn=jduke,ou=Roles,ou=example2,${dnSuffix}
> objectClass: top
> objectClass: organizationalRole
> description: cn=Echo,ou=Roles,ou=example2,${dnSuffix}
> description: cn=TheDuke,ou=Roles,ou=example2,${dnSuffix}
> cn: jduke
> {code}
> User will have roles jduke, Echo and TheDuke.
> This was possible with Picketbox with this configuration
> {code}
> EapSetupTask roleAttributesConfiguration =
> new LdapExtSecurityDomainBuilder(SECURITY_DOMAIN_NAME_PREFIX + DEP2)
> .prepareDefaultForLdapServer(ldapServer)
> .baseCtxDN("ou=People,ou=example2," + ldapServer.getDNSuffix())
> .rolesCtxDN("ou=Roles,ou=example2," + ldapServer.getDNSuffix())
> .referral("ignore")
> .roleFilter("(|(objectClass=referral)(cn={0}))")
> .roleAttributeID("description")
> .roleAttributeIsDN("true")
> .roleNameAttributeID("cn")
> .roleRecursion("0")
> .configure();
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months