July 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6809) Web authentication not treating "**" role constraint as expected

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6809?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-6809: -------------------------------------- After re-reading the spec I am not 100% sure that your interpretation is correct. The section you mention only applies to isUserInRole, while the section on declarative security has no corresponding section. I have created a servlet spec issue to ask for clarification on this: https://java.net/jira/browse/SERVLET_SPEC-158 As it is though Undertow currently follows the letter of the spec. > Web authentication not treating "**" role constraint as expected > ---------------------------------------------------------------- > > Key: WFLY-6809 > URL: https://issues.jboss.org/browse/WFLY-6809 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Guillermo González de Agüero > Assignee: Stuart Douglas > Attachments: rolestest.war > > > Servlet spec 3.1 states at point 13.3: > ??If the role-name of the security-role to be tested is “**”, and the application has NOT declared an application security-role with role-name “**”, isUserInRole must only return true if the user has been authenticated; that is, only when getRemoteUser and getUserPrincipal would both return a non-null value. Otherwise, the container must check the user for membership in the application role.?? > But Undertow treats the special role "**" as any other. With the following web.xml authorization succeeds, but authorization fails (403): > {code:xml} > <?xml version="1.0" encoding="UTF-8"?> > <web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd" > version="3.1"> > <security-constraint> > <web-resource-collection> > <url-pattern>/*</url-pattern> > </web-resource-collection> > <auth-constraint> > <role-name>**</role-name> > </auth-constraint> > </security-constraint> > <login-config> > <auth-method>BASIC</auth-method> > </login-config> > </web-app> > {code} > With the following, and authenticating a user that has a role "**", the requested page is shown: > {code:xml} > <?xml version="1.0" encoding="UTF-8"?> > <web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd" > version="3.1"> > <security-constraint> > <web-resource-collection> > <url-pattern>/*</url-pattern> > </web-resource-collection> > <auth-constraint> > <role-name>**</role-name> > </auth-constraint> > </security-constraint> > <login-config> > <auth-method>BASIC</auth-method> > </login-config> > <security-role> > <role-name>**</role-name> > </security-role> > </web-app> > {code} > Reproducer war is attached. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6818) Web authentication not treating "**" role constraint as expected

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-6818: ------------------------------------ Summary: Web authentication not treating "**" role constraint as expected Key: WFLY-6818 URL: https://issues.jboss.org/browse/WFLY-6818 Project: WildFly Issue Type: Bug Components: Web (Undertow) Affects Versions: 10.0.0.Final Reporter: Guillermo González de Agüero Assignee: Stuart Douglas Servlet spec 3.1 states at point 13.3: ??If the role-name of the security-role to be tested is “**”, and the application has NOT declared an application security-role with role-name “**”, isUserInRole must only return true if the user has been authenticated; that is, only when getRemoteUser and getUserPrincipal would both return a non-null value. Otherwise, the container must check the user for membership in the application role.?? But Undertow treats the special role "**" as any other. With the following web.xml authorization succeeds, but authorization fails (403): {code:xml} <?xml version="1.0" encoding="UTF-8"?> <web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd" version="3.1"> <security-constraint> <web-resource-collection> <url-pattern>/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>**</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> </login-config> </web-app> {code} With the following, and authenticating a user that has a role "**", the requested page is shown: {code:xml} <?xml version="1.0" encoding="UTF-8"?> <web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd" version="3.1"> <security-constraint> <web-resource-collection> <url-pattern>/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>**</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> </login-config> <security-role> <role-name>**</role-name> </security-role> </web-app> {code} Reproducer war is attached. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6817) JASPICSecureResponseHandler.handleRequest throws NullPointerException when redirecting for CONFIDENTIAL transport guarantee

by Aaron Ogburn (JIRA)

Aaron Ogburn created WFLY-6817: ---------------------------------- Summary: JASPICSecureResponseHandler.handleRequest throws NullPointerException when redirecting for CONFIDENTIAL transport guarantee Key: WFLY-6817 URL: https://issues.jboss.org/browse/WFLY-6817 Project: WildFly Issue Type: Bug Components: Web (Undertow) Affects Versions: 10.0.0.Final Reporter: Aaron Ogburn Assignee: Stuart Douglas JASPICSecureResponseHandler.handleRequest can throw a NPE for a redirect from a CONFIDENTIAL transport guarantee: {code} java.lang.NullPointerException at org.wildfly.extension.undertow.security.jaspi.JASPICSecureResponseHandler.handleRequest(JASPICSecureResponseHandler.java:35) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:285) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) {code} This occurs because io.undertow.security.handlers.AbstractConfidentialityHandler generates the redirect before any JASPICContext is placed on the request, so JASPICSecureResponseHandler sees the null. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6817) JASPICSecureResponseHandler.handleRequest throws NullPointerException when redirecting for CONFIDENTIAL transport guarantee

by Aaron Ogburn (JIRA)

[ https://issues.jboss.org/browse/WFLY-6817?page=com.atlassian.jira.plugin.... ] Aaron Ogburn updated WFLY-6817: ------------------------------- Attachment: standalone.xml > JASPICSecureResponseHandler.handleRequest throws NullPointerException when redirecting for CONFIDENTIAL transport guarantee > --------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-6817 > URL: https://issues.jboss.org/browse/WFLY-6817 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Aaron Ogburn > Assignee: Stuart Douglas > Attachments: standalone.xml > > > JASPICSecureResponseHandler.handleRequest can throw a NPE for a redirect from a CONFIDENTIAL transport guarantee: > {code} > java.lang.NullPointerException > at org.wildfly.extension.undertow.security.jaspi.JASPICSecureResponseHandler.handleRequest(JASPICSecureResponseHandler.java:35) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:285) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > {code} > This occurs because io.undertow.security.handlers.AbstractConfidentialityHandler generates the redirect before any JASPICContext is placed on the request, so JASPICSecureResponseHandler sees the null. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6816) messaging-artemis xsd is missing the initial-connect-attempts attribute

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-6816?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-6816: ----------------------------------- Summary: messaging-artemis xsd is missing the initial-connect-attempts attribute (was: messaging-artemix xsd is missing the initial-connect-attempts attribute) > messaging-artemis xsd is missing the initial-connect-attempts attribute > ----------------------------------------------------------------------- > > Key: WFLY-6816 > URL: https://issues.jboss.org/browse/WFLY-6816 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 10.1.0.Final > > > The cluster-connection element is missing the initial-connect-attempts attribute. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6816) messaging-artemismq xsd is missing the initial-connect-attempts attribute

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-6816?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-6816: ----------------------------------- Summary: messaging-artemismq xsd is missing the initial-connect-attempts attribute (was: messaging-artemis xsd is missing the initial-connect-attempts attribute) > messaging-artemismq xsd is missing the initial-connect-attempts attribute > ------------------------------------------------------------------------- > > Key: WFLY-6816 > URL: https://issues.jboss.org/browse/WFLY-6816 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 10.1.0.Final > > > The cluster-connection element is missing the initial-connect-attempts attribute. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6816) messaging-artemix xsd is missing the initial-connect-attempts attribute

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-6816: -------------------------------------- Summary: messaging-artemix xsd is missing the initial-connect-attempts attribute Key: WFLY-6816 URL: https://issues.jboss.org/browse/WFLY-6816 Project: WildFly Issue Type: Bug Components: JMS Affects Versions: 10.0.0.Final Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 10.1.0.Final The cluster-connection element is missing the initial-connect-attempts attribute. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6815) JDOM cannot create default parser

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6815?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-6815: ----------------------------------- where does this happen? what build of jdk9? > JDOM cannot create default parser > --------------------------------- > > Key: WFLY-6815 > URL: https://issues.jboss.org/browse/WFLY-6815 > Project: WildFly > Issue Type: Sub-task > Components: Build System > Reporter: Thomas Diesler > Assignee: Thomas Diesler > Fix For: 10.1.0.Final > > > {code} > org.jdom.JDOMException: Could not load default SAX parser: org.apache.xerces.parsers.SAXParser: SAX2 driver class org.apache.xerces.parsers.SAXParser not found: org.apache.xerces.parsers.SAXParser from [Module "org.wildfly.extras.config:main" from local module loader @a3d8174 (finder: local module finder @1ba9117e (roots: /Users/tdiesler/git/wildfly-camel/itests/standalone/smoke/target/wildfly-10.1.0.Final-SNAPSHOT/modules,/Users/tdiesler/git/wildfly-camel/itests/standalone/smoke/target/wildfly-10.1.0.Final-SNAPSHOT/modules/system/layers/fuse,/Users/tdiesler/git/wildfly-camel/itests/standalone/smoke/target/wildfly-10.1.0.Final-SNAPSHOT/modules/system/layers/base))] > at org.jdom.input.SAXBuilder.createParser(SAXBuilder.java:649) > at org.jdom.input.SAXBuilder.build(SAXBuilder.java:489) > at org.jdom.input.SAXBuilder.build(SAXBuilder.java:905) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5739) Subject not populated with groups/roles when authenticated via JASPIC

by István Tóth (JIRA)

[ https://issues.jboss.org/browse/WFLY-5739?page=com.atlassian.jira.plugin.... ] István Tóth commented on WFLY-5739: ----------------------------------- I have just sent PR https://github.com/wildfly/wildfly/pull/9003 that fixes it (for me) Thanks for [~ggam]'s help > Subject not populated with groups/roles when authenticated via JASPIC > --------------------------------------------------------------------- > > Key: WFLY-5739 > URL: https://issues.jboss.org/browse/WFLY-5739 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.0.0.CR4 > Reporter: Arjan t > Assignee: Darran Lofthouse > Labels: jacc, jaspic > Attachments: CustomAuth.zip, picketbox.zip > > > After having authenticated via JASPIC, requesting the current {{Subject}} via JACC and then using that for permission checks fails. > For instance the following code will always set {{hasAccess}} to false given that "/protected/*" requires a role and the authenticated user is in that role: > {code:java} > Subject subject = (Subject) PolicyContext.getContext("javax.security.auth.Subject.container"); > > boolean hasAccess = Policy.getPolicy().implies( > new ProtectionDomain( > new CodeSource(null, (Certificate[]) null), > null, null, > subject.getPrincipals().toArray(new Principal[subject.getPrincipals().size()]) > ), > new WebResourcePermission("/protected/Servlet", "GET")) > ; > {code} > As it appears, the problem originates from the fact that {{subject.getPrincipals()}} does not contain the roles. > This can be traced back to {{org.jboss.security.auth.callback.JASPICallbackHandler.handleCallBack}}, where it becomes clear that the roles are only put into the "util", but not in the "authenticatedSubject": > {code:java} > String[] rolesArray = groupPrincipalCallback.getGroups(); > int sizeOfRoles = rolesArray != null ? rolesArray.length : 0; > > if( sizeOfRoles > 0 ) > { > List<Role> rolesList = new ArrayList<Role>(); > for( int i = 0; i < sizeOfRoles ; i++ ) > { > Role role = new SimpleRole( rolesArray[ i ] ); > rolesList.add( role ); > } > RoleGroup roles = new SimpleRoleGroup( SecurityConstants.ROLES_IDENTIFIER, rolesList ); > // if the current security context already has roles, we merge them with the incoming roles. > RoleGroup currentRoles = currentSC.getUtil().getRoles(); > // *** ROLES ARE ONLY SET HERE *** > if (currentRoles != null) { > currentRoles.addAll(roles.getRoles()); > } > else { > currentSC.getUtil().setRoles( roles ); > } > } > // *** BELOW THIS LINE ROLES ARE NOT REFERENCED ANYMORE > // *** SUBJECT IS NOT POPULATED WITH ANY ROLE INFO > Subject subject = groupPrincipalCallback.getSubject(); > if( subject != null ) > { > // if the current security context already has an associated subject, we merge it with the incoming subject. > Subject currentSubject = currentSC.getSubjectInfo().getAuthenticatedSubject(); > if (currentSubject != null) { > subject.getPrincipals().addAll(currentSubject.getPrincipals()); > subject.getPublicCredentials().addAll(currentSubject.getPublicCredentials()); > subject.getPrivateCredentials().addAll(currentSubject.getPrivateCredentials()); > } > currentSC.getSubjectInfo().setAuthenticatedSubject(subject); > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2088) ArrayIndexOutOfBoundsException on ClassConfigurator.get()

by Manuel Dominguez Sarmiento (JIRA)

[ https://issues.jboss.org/browse/JGRP-2088?page=com.atlassian.jira.plugin.... ] Manuel Dominguez Sarmiento commented on JGRP-2088: -------------------------------------------------- Thanks. However note that ENCRYPT.java as shipped with jgroups-3.6.10.Final-sources.jar does not contain the @Deprecated comments (see attached file). Download the package from Sourceforge and check whether those sources are actually synced with the 3.6.10 release. > ArrayIndexOutOfBoundsException on ClassConfigurator.get() > --------------------------------------------------------- > > Key: JGRP-2088 > URL: https://issues.jboss.org/browse/JGRP-2088 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.10 > Reporter: Manuel Dominguez Sarmiento > Assignee: Bela Ban > Fix For: 3.6.11, 4.0 > > Attachments: ENCRYPT.java, jgroups.xml > > > See the following stack trace: > [ERROR] 2016-07-09 14:26:05 [UDP-multicast receiver,shared=jgroups-shared-transport] - JGRP000030: null: failed handling incoming message: java.lang.ArrayIndexOutOfBoundsException: -1 > java.lang.ArrayIndexOutOfBoundsException: -1 > at org.jgroups.conf.ClassConfigurator.get(ClassConfigurator.java:161) > at org.jgroups.Message.readHeader(Message.java:936) > at org.jgroups.Message.readFrom(Message.java:811) > at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1712) > at org.jgroups.protocols.TP.receive(TP.java:1654) > at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701) > at java.lang.Thread.run(Thread.java:745) > Stepping through the code with the debugger shows that the following line is failing at ClassConfigurator.get() with magic = -1 thus the java.lang.ArrayIndexOutOfBoundsException > return magic < 1024 ? magicMap[magic] : (Class)magicMapUser.get(Short.valueOf(magic)); > See attached jgroups.xml for configuration. This showed up when upgrading to 3.6.10 from 3.6.8 which worked fine. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2016