[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
[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
[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
[JBoss JIRA] (ELY-1671) Unable to build javadoc on JDK 10
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1671?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1671:
----------------------------------
Fix Version/s: 1.7.0.CR3
(was: 1.7.0.CR2)
> Unable to build javadoc on JDK 10
> ---------------------------------
>
> Key: ELY-1671
> URL: https://issues.jboss.org/browse/ELY-1671
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Documentation
> Reporter: Darran Lofthouse
> Assignee: Justin Cook
> Priority: Blocker
> Fix For: 1.7.0.CR3
>
>
> {noformat}
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 1.854 s
> [INFO] Finished at: 2018-09-19T13:50:48+01:00
> [INFO] Final Memory: 26M/108M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:3.0.0-M1:javadoc (default-cli) on project wildfly-elytron: An error has occurred in Javadoc report generation:
> [ERROR] Exit code: 1 - javadoc: warning - The old Doclet and Taglet APIs in the packages
> [ERROR] com.sun.javadoc, com.sun.tools.doclets and their implementations
> [ERROR] are planned to be removed in a future JDK release. These
> [ERROR] components have been superseded by the new APIs in jdk.javadoc.doclet.
> [ERROR] Users are strongly recommended to migrate to the new APIs.
> [ERROR] javadoc: error - invalid flag: -Xdoclint:none
> [ERROR]
> [ERROR] Command line was: /home/darranl/applications/java/jdk-10.0.2/bin/javadoc @options @argfile
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in '/home/darranl/src/community/wildfly-elytron/target/site/apidocs/api-javadoc' dir.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years
[JBoss JIRA] (ELY-1668) LDAP searchScope=OBJECT_SCOPE Elytron alternative
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1668?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1668:
----------------------------------
Fix Version/s: 1.7.0.CR3
(was: 1.7.0.CR2)
> LDAP searchScope=OBJECT_SCOPE Elytron alternative
> -------------------------------------------------
>
> Key: ELY-1668
> URL: https://issues.jboss.org/browse/ELY-1668
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.6.1.Final
> Reporter: Martin Choma
> Priority: Critical
> Fix For: 1.7.0.CR3
>
>
> During comparing PicketBox an Elytron we came to one scenario which I am not sure if is covered by Elytron.
> "As a user I am able to authenticate and authorize into web application secured by LDAP (where the same is used for storing identities and roles) and roles are stored in tree structure and should be only referenced object." Author is Ondra Lukas which is not with us anymore so I tried to think about what could this be about? Based on context I came to conclusion this is about OBJECT_SCOPE value of property searchScope.
> Could you revise if same is possible with Elytron? But anyway I am not sure how that feature can be useful. But maybe there is some corner case it can be useful I am not aware of.
> {code}
> dn: ou=People,${dnSuffix}
> objectclass: top
> objectclass: organizationalUnit
> ou: People
> dn: uid=jduke,ou=People,${dnSuffix}
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> uid: jduke
> cn: Java Duke
> sn: Duke
> userPassword: Password1
> dn: ou=RolesLevel1,${dnSuffix}
> objectclass: top
> objectclass: organizationalUnit
> ou: RolesLevel1
> dn: cn=RoleUnderLevel1,ou=RolesLevel1,${dnSuffix}
> objectclass: top
> objectclass: groupOfNames
> cn: RoleUnderLevel1
> member: uid=jduke,ou=People,${dnSuffix}
> description: the RoleUnderLevel1 group
> {code}
> [1] https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years
[JBoss JIRA] (WFLY-10022) [Artemis 2.x Upgrade] File leak - Artemis crashes on Critical IO Error, shutting down the server. file=NIOSequentialFile .../largemessages/55851.msg, message=.../largemessages/55851.msg (Too many open files)
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-10022?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-10022:
---------------------------------
Fix Version/s: 14.0.0.Final
> [Artemis 2.x Upgrade] File leak - Artemis crashes on Critical IO Error, shutting down the server. file=NIOSequentialFile .../largemessages/55851.msg, message=.../largemessages/55851.msg (Too many open files)
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10022
> URL: https://issues.jboss.org/browse/WFLY-10022
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
> Fix For: 14.0.0.Final
>
>
> There is file leak in Artemis master branch (577b62d5210cdcc0f86ab9bb1b24e944c877dfe7) when large messages are consumed from topic. This is regression against Artemis 1.5.x.
> Test Scenario:
> * Start WF12 (Jeff's WF WFLY-9407_upgrade_artemis_2.5.0 branch - 06c878a313d3cad323889d017e60fd5533204d1a) with deployed "testTopic"
> * create durable subscriptions on testTopic
> * start sending large messages on testTopic
> * subscribers start to consume one by one so there is a huge difference in number of consumed messages between subscriptions
> Pass Criteria: Subscribers must receive correct number of messages.
> Actual Result:
> Artemis server shutdown/crashes itself on (ulimit for max number of open files was set to 8196):
> {code}
> 15:21:54,717 WARN [org.apache.activemq.artemis.core.server] (Thread-21 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@1787a3ac)) AMQ222010: Critical IO Error, shutting down the server. file=NIOSequentialFile /home/mnovak/hornetq_eap6_dev/internal/eap-tests-hornetq/scripts/journal-A/largemessages/55851.msg, message=/home/mnovak/hornetq_eap6_dev/internal/eap-tests-hornetq/scripts/journal-A/largemessages/55851.msg (Too many open files): ActiveMQIOErrorException[errorType=IO_ERROR message=/home/mnovak/hornetq_eap6_dev/internal/eap-tests-hornetq/scripts/journal-A/largemessages/55851.msg (Too many open files)]
> at org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.open(NIOSequentialFile.java:87) [artemis-journal-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.open(NIOSequentialFile.java:73) [artemis-journal-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.persistence.impl.journal.LargeServerMessageImpl.openFile(LargeServerMessageImpl.java:397) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.persistence.impl.journal.LargeServerMessageImpl.validateFile(LargeServerMessageImpl.java:376) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.createLargeMessage(JournalStorageManager.java:495) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.sendLarge(ServerSessionPacketHandler.java:937) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.slowPacketHandler(ServerSessionPacketHandler.java:302) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.onMessagePacket(ServerSessionPacketHandler.java:281) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.utils.actors.Actor.doTask(Actor.java:33) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> Caused by: java.io.FileNotFoundException: /home/mnovak/hornetq_eap6_dev/internal/eap-tests-hornetq/scripts/journal-A/largemessages/55851.msg (Too many open files)
> at java.io.RandomAccessFile.open0(Native Method) [rt.jar:1.8.0_131]
> at java.io.RandomAccessFile.open(RandomAccessFile.java:316) [rt.jar:1.8.0_131]
> at java.io.RandomAccessFile.<init>(RandomAccessFile.java:243) [rt.jar:1.8.0_131]
> at org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.open(NIOSequentialFile.java:79) [artemis-journal-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> ... 15 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years
[JBoss JIRA] (WFLY-10494) HHH-12651 org.hibernate.Session.*Query(Ljava/lang/String) methods return different types in 5.1 and 5.3
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-10494?page=com.atlassian.jira.plugin... ]
Scott Marlow closed WFLY-10494.
-------------------------------
> HHH-12651 org.hibernate.Session.*Query(Ljava/lang/String) methods return different types in 5.1 and 5.3
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10494
> URL: https://issues.jboss.org/browse/WFLY-10494
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 13.0.0.Final
> Reporter: Martin Simka
> Assignee: Scott Marlow
> Priority: Blocker
> Labels: blocker-WF14
> Fix For: 14.0.0.Beta2
>
>
> https://hibernate.atlassian.net/browse/HHH-12651
> although mentioned in HHH-12424, it doesn't seem to be resolved
> in 5.1
> org.hibernate.Session.createQuery(Ljava/lang/String;)Lorg/hibernate/Query
> in 5.3
> org.hibernate.Session.createQuery(Ljava/lang/String;)Lorg/hibernate.query.Query
> It happens when code compiled with Hibernate ORM 5.1 is run with Hibernate ORM 5.3
> I attached very simple reproducer class.
> {code}
> # compile with Hibernate 5.1
> javac App.java -cp ~/.m2/repository/org/hibernate/hibernate-core/5.1.9.Final/hibernate-core-5.1.9.Final.jar
> # run with 5.1 => ok
> java -cp .:/home/msimka/.m2/repository/org/hibernate/hibernate-core/5.1.9.Final/hibernate-core-5.1.9.Final.jar App
> # run with 5.3 => fail
> java -cp .:/home/msimka/.m2/repository/org/hibernate/hibernate-core/5.3.1.Final/hibernate-core-5.3.1.Final.jar:/home/msimka/.m2/repository/javax/persistence/javax.persistence-api/2.2/javax.persistence-api-2.2.jar App
> Exception in thread "main" java.lang.NoSuchMethodError: org.hibernate.Session.createQuery(Ljava/lang/String;)Lorg/hibernate/Query;
> at App.main(App.java:35)
> {code}
> other methods with the same issue:
> java.lang.NoSuchMethodError: org.hibernate.Session.getNamedQuery(Ljava/lang/String;)Lorg/hibernate/Query;
> java.lang.NoSuchMethodError: org.hibernate.Session.createSQLQuery(Ljava/lang/String;)Lorg/hibernate/SQLQuery;
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years