August 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-5346) Upgrade PicketBox to 4.0.11.Final

by Stefan Guilhen (JIRA)

Stefan Guilhen created AS7-5346: ----------------------------------- Summary: Upgrade PicketBox to 4.0.11.Final Key: AS7-5346 URL: https://issues.jboss.org/browse/AS7-5346 Project: Application Server 7 Issue Type: Task Components: Security Reporter: Stefan Guilhen Assignee: Stefan Guilhen -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
1
0 / 0

[JBoss JIRA] (SECURITY-684) Release PicketBox 4.0.11.Final

by Stefan Guilhen (JIRA)

Stefan Guilhen created SECURITY-684: --------------------------------------- Summary: Release PicketBox 4.0.11.Final Key: SECURITY-684 URL: https://issues.jboss.org/browse/SECURITY-684 Project: PicketBox (JBoss Security and Identity Management) Issue Type: Task Security Level: Public (Everyone can see) Components: JBossSX, Security SPI Reporter: Stefan Guilhen Assignee: Stefan Guilhen -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
1
0 / 0

[JBoss JIRA] (SECURITY-683) Release PicketBox 4.0.10.Final

by Stefan Guilhen (JIRA)

Stefan Guilhen created SECURITY-683: --------------------------------------- Summary: Release PicketBox 4.0.10.Final Key: SECURITY-683 URL: https://issues.jboss.org/browse/SECURITY-683 Project: PicketBox (JBoss Security and Identity Management) Issue Type: Task Security Level: Public (Everyone can see) Components: JBossSX, Security SPI Reporter: Stefan Guilhen Assignee: Stefan Guilhen -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
1
0 / 0

[JBoss JIRA] (AS7-5345) Upgrade PicketLink Libraries to 2.1.4.Final

by Pedro Igor (JIRA)

Pedro Igor created AS7-5345: ------------------------------- Summary: Upgrade PicketLink Libraries to 2.1.4.Final Key: AS7-5345 URL: https://issues.jboss.org/browse/AS7-5345 Project: Application Server 7 Issue Type: Component Upgrade Components: Security Reporter: Pedro Igor Assignee: Anil Saldhana Fix For: 7.1.2.Final (EAP) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
5
0 / 0

[JBoss JIRA] (AS7-5337) Vault utility outputing incorrect shared key values

by Darran Lofthouse (JIRA)

Darran Lofthouse created AS7-5337: ------------------------------------- Summary: Vault utility outputing incorrect shared key values Key: AS7-5337 URL: https://issues.jboss.org/browse/AS7-5337 Project: Application Server 7 Issue Type: Bug Components: Security Environment: No affects version as this is master as on 10th August 2012 - the 7.1 branch does not show this behaviour. Reporter: Darran Lofthouse Assignee: Anil Saldhana Fix For: 7.2.0.Alpha1 Adding a new vault entry results in the following (invalid) output - the shared key appears to be an object reference: - {code} ******************************************** Vault Block:darranl Attribute Name:password Shared Key:[B@79de256f Configuration should be done as follows: VAULT::darranl::password::[B@79de256f ******************************************** {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

4
4
0 / 0

[JBoss JIRA] (SECURITY-680) AbstractServerLoginModule.commit() always adds the identity Principal to the CallerPrincipal group

by Tom Fonteyne (JIRA)

Tom Fonteyne created SECURITY-680: ------------------------------------- Summary: AbstractServerLoginModule.commit() always adds the identity Principal to the CallerPrincipal group Key: SECURITY-680 URL: https://issues.jboss.org/browse/SECURITY-680 Project: PicketBox (JBoss Security and Identity Management) Issue Type: Bug Security Level: Public (Everyone can see) Components: JBossSX Affects Versions: PicketBox_v4_0_9.Final Environment: JBoss EAP 6.0 Reporter: Tom Fonteyne Assignee: Anil Saldhana Since EAP6, AbstractServerLoginModule.commit() contains the following piece of code just before getRoleSets() is called: // add the CallerPrincipal group Group callerGroup = getCallerPrincipalGroup(principals); if (callerGroup == null) { callerGroup = new SimpleGroup(SecurityConstants.CALLER_PRINCIPAL_GROUP); callerGroup.addMember(identity); principals.add(callerGroup); } Since getRoleSets() should also return the CallerPrincipal group (as specified in the documentation), the identity is often added to the CallerPrincipal. As a result, the Principal used when authenticating is sometimes not the desired CallerPrincipal element but the identity (which one is determined by the backing HashMap of SimpleGroup). This can lead to security problems. >From the Javadoc of getRoleSets(): "A second common group is "CallerPrincipal" that provides the application identity of the user rather than the security domain identity." JBoss EAP 6 however creates this CallerPrincipal group itself with the identity SimplePrincipal as its sole member. This group is then merged with the CallerPrincipal group returned by getRoleSets(), causing the two members. One solution could be to move the above piece of code to the end of the commit() method. This way, if getRoleSets() returns the CallerPrincipal group, this will remain unmodified, and if it does not then a new CallerPrincipal group will be created. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

2
3
0 / 0

[JBoss JIRA] (SECURITY-660) Convert project to use i18n logging and exceptions

by James Perkins (JIRA)

James Perkins created SECURITY-660: -------------------------------------- Summary: Convert project to use i18n logging and exceptions Key: SECURITY-660 URL: https://issues.jboss.org/browse/SECURITY-660 Project: PicketBox (JBoss Security and Identity Management) Issue Type: Task Security Level: Public (Everyone can see) Reporter: James Perkins Assignee: Anil Saldhana As per [ANDIAMO-7|https://issues.jboss.org/browse/ANDIAMO-7] all messages (logged and exceptions) need a unique id. This need to be done using JBoss Logging, [ANDIAMO-2|https://issues.jboss.org/browse/ANDIAMO-2]. See [https://community.jboss.org/docs/DOC-18453] for information on configuring the loggers and message bundles. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

3
2
0 / 0

[JBoss JIRA] (JBJCA-885) Synchronize access to MDR / RAR

by Jesper Pedersen (JIRA)

Jesper Pedersen created JBJCA-885: ------------------------------------- Summary: Synchronize access to MDR / RAR Key: JBJCA-885 URL: https://issues.jboss.org/browse/JBJCA-885 Project: IronJacamar Issue Type: Bug Components: Core Affects Versions: 1.1.0.Beta1, 1.0.12.Final Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.0.13.Final, 1.1.0.Beta2 Synchronize access to core datastructures -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
1
0 / 0

[JBoss JIRA] (LOGTOOL-51) Logging generation processing breaks APT rules by loading classes via reflection

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-51?page=com.atlassian.jira.plugin... ] James Perkins edited comment on LOGTOOL-51 at 8/10/12 2:17 PM: --------------------------------------------------------------- Pull request sent https://github.com/jboss-logging/jboss-logging-tools/pull/5 was (Author: jamezp): Pull request sent https://github.com/jboss-logging/jboss-logging-tools/pull/4 > Logging generation processing breaks APT rules by loading classes via reflection > -------------------------------------------------------------------------------- > > Key: LOGTOOL-51 > URL: https://issues.jboss.org/browse/LOGTOOL-51 > Project: Log Tool > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: JBDS 5.5.0.CR1 > Reporter: Fred Bricon > Assignee: David Lloyd > Priority: Blocker > Attachments: codemodel-2.6.jar, jboss-logging-processor-1.1.0.Beta1-SNAPSHOT.jar > > > JBDS 5.5.0.CR1 embeds [m2e-apt|https://github.com/jbosstools/m2e-apt], which automatically enables Eclipse JDT Annotation Processor Toolkit. > When importing the [server|https://github.com/jbossas/jboss-as/tree/master/server] module from http://github.com/jbossas/jboss-as.git (also happens for other modules), Eclipse starts crashing (see JBIDE-12087) with errors like : > {noformat} > javax.xml.parsers.FactoryConfigurationError: Provider __redirected.__DocumentBuilderFactory not found > at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:127) > at org.eclipse.jdt.apt.core.internal.util.FactoryPathUtil.decodeFactoryPath(FactoryPathUtil.java:222) > at org.eclipse.jdt.apt.core.internal.util.FactoryPathUtil.readFactoryPathFile(FactoryPathUtil.java:115) > at org.eclipse.jdt.apt.core.internal.util.FactoryPathUtil.calculatePath(FactoryPathUtil.java:342) > at org.eclipse.jdt.apt.core.internal.util.FactoryPathUtil.getFactoryPath(FactoryPathUtil.java:429) > at org.eclipse.jdt.apt.core.internal.AnnotationProcessorFactoryLoader.getJava6FactoriesAndAttributesForProject(AnnotationProcessorFactoryLoader.java:420) > at org.eclipse.jdt.internal.apt.pluggable.core.dispatch.IdeAnnotationProcessorManager.processAnnotations(IdeAnnotationProcessorManager.java:130) > at org.eclipse.jdt.internal.compiler.Compiler.processAnnotations(Compiler.java:813) > at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:432) > at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:364) > at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.compile(BatchImageBuilder.java:178) > at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:301) > at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:60) > at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:254) > at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:173) > at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:728) > at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) > at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199) > at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:239) > at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292) > at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) > at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295) > at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:351) > at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:374) > at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143) > at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241) > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) > Caused by: java.lang.ClassNotFoundException: __redirected/__DocumentBuilderFactory > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:264) > at javax.xml.parsers.FactoryFinder.getProviderClass(FactoryFinder.java:119) > at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:144) > at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:185) > at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:121) > {noformat} > It turns out the Eclipse System Properties have been changed to use javax.xml.parsers.SAXParserFactory=__redirected/__DocumentBuilderFactory > I tracked the code responsible with messing with the properties : > {noformat} > Thread [Worker-24] (Suspended (breakpoint at line 779 in System)) > System.setProperty(String, String) line: 779 > __SAXParserFactory.<clinit>() line: 68 > __JAXPRedirected.initAll() line: 80 > Module$1.run() line: 126 > Module$1.run() line: 113 > AccessController.doPrivileged(PrivilegedAction<T>) line: not available [native method] > Module.<clinit>() line: 113 > Class<T>.forName0(String, boolean, ClassLoader) line: not available [native method] > Class<T>.forName(String) line: 186 <====== org.jboss.modules.Module > JCodeModel.ref(String) line: 363 > MessageBundleImplementor(ImplementationClassModel).createBundleMethod(MessageMethod, JMethod, JMethod, JVar) line: 150 > MessageBundleImplementor.generateModel() line: 86 > MessageBundleImplementor(ClassModel).create(JavaFileObject) line: 104 > ImplementationClassGenerator.processTypeElement(TypeElement, TypeElement, MessageInterface) line: 63 > LoggingToolsProcessor.process(Set<TypeElement>, RoundEnvironment) line: 155 > RoundDispatcher.handleProcessor(ProcessorInfo) line: 139 > RoundDispatcher.round() line: 121 > IdeAnnotationProcessorManager(BaseAnnotationProcessorManager).processAnnotations(CompilationUnitDeclaration[], ReferenceBinding[], boolean) line: 159 > IdeAnnotationProcessorManager.processAnnotations(CompilationUnitDeclaration[], ReferenceBinding[], boolean) line: 134 > Compiler.processAnnotations() line: 813 > Compiler.compile(ICompilationUnit[]) line: 432 > BatchImageBuilder(AbstractImageBuilder).compile(SourceFile[], SourceFile[], boolean) line: 364 > BatchImageBuilder.compile(SourceFile[], SourceFile[], boolean) line: 178 > BatchImageBuilder(AbstractImageBuilder).compile(SourceFile[]) line: 301 > BatchImageBuilder.build() line: 60 > JavaBuilder.buildAll() line: 254 > JavaBuilder.build(int, Map, IProgressMonitor) line: 173 > BuildManager$2.run() line: 728 > SafeRunner.run(ISafeRunnable) line: 42 > BuildManager.basicBuild(int, IncrementalProjectBuilder, Map<String,String>, MultiStatus, IProgressMonitor) line: 199 > BuildManager.basicBuild(IBuildConfiguration, int, IBuildContext, ICommand[], MultiStatus, IProgressMonitor) line: 239 > BuildManager$1.run() line: 292 > SafeRunner.run(ISafeRunnable) line: 42 > BuildManager.basicBuild(IBuildConfiguration, int, IBuildContext, MultiStatus, IProgressMonitor) line: 295 > BuildManager.basicBuildLoop(IBuildConfiguration[], IBuildConfiguration[], int, MultiStatus, IProgressMonitor) line: 351 > BuildManager.build(IBuildConfiguration[], IBuildConfiguration[], int, IProgressMonitor) line: 374 > AutoBuildJob.doBuild(IProgressMonitor) line: 143 > AutoBuildJob.run(IProgressMonitor) line: 241 > Worker.run() line: 54 > {noformat} > That stacktrace represents the processing of https://github.com/jbossas/jboss-as/blob/master/server/src/main/java/org/... > So basically, whenever a Logger has a dependency to the [org.jboss.modules.Module|https://github.com/jbossas/jboss-modules/blob/ma...] class, stuff starts hitting the fan. > Classes should not be loaded by reflection during APT processing to avoid such issues - it should use the API provided by APT to iterate over the classes metadata provided by the compiler and not depend on com.sun.*.internal classes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AS7-5330) HornetQSecurityManagerAS7 is not restoring the original security context when it pops its own

by Ed Roberts (JIRA)

Ed Roberts created AS7-5330: ------------------------------- Summary: HornetQSecurityManagerAS7 is not restoring the original security context when it pops its own Key: AS7-5330 URL: https://issues.jboss.org/browse/AS7-5330 Project: Application Server 7 Issue Type: Bug Components: JMS Affects Versions: 7.1.1.Final Environment: Windows XP SP2 JDK 1.6.0_32 Eclipse Indigo for JMS Client invocation Reporter: Ed Roberts Assignee: Andy Taylor I have added the HornetQ acceptor, connector and connection factory to allow JMS over HTTP tunneling. I tested a message send using an external JMS Client. The following exception is thrown during the transmission 2012-08-09 10:50:07,155 ERROR [org.apache.catalina.connector.CoyoteAdapter](http-executor-threads - 1) An exception or error occurred in the container during the request processing: java.lang.IllegalStateException: JBAS018053: No security context found at org.jboss.as.web.security.SecurityActions$6.run(SecurityActions.java:136) at org.jboss.as.web.security.SecurityActions$6.run(SecurityActions.java:130) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.as.web.security.SecurityActions.popRunAsIdentity(SecurityActions.java:130) at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:155) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:567) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:518) at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33) at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:801) at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45) at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:842) at java.lang.Thread.run(Thread.java:662) at org.jboss.threads.JBossThread.run(JBossThread.java:122) After some debugging, I can make out that this has exposed a fault in the HornetQSecurityManagerAS7. When it is active, it pushes the "other" security context from my configuration into the active security context, but when done and pops its security context, it does not restore the original, which was the jboss-web-policy. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

2
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2012