May 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-466) Detect JBossWS Configuration for @PermitAll endpoints within Undertow subsystem.

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-466?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-466: ------------------------------ Fix Version/s: 10.0.0.Alpha3 (was: 10.0.0.Alpha2) > Detect JBossWS Configuration for @PermitAll endpoints within Undertow subsystem. > -------------------------------------------------------------------------------- > > Key: WFLY-466 > URL: https://issues.jboss.org/browse/WFLY-466 > Project: WildFly > Issue Type: Task > Components: Web (Undertow) > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 10.0.0.Alpha3 > > > UNDERTOW-38 has added the possibility of deploying web applications where authentication is mandated but no authorization checks are performed - this is required for integration use cases such as EJB endpoints where authorization checks are being left to the EJB container. > This task is to update the Undertow susbsystem to detect this scenario and enable the new mode for UNDERTOW-38. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-447) Connection Reauthentication and Security Propagation

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-447?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-447: ------------------------------ Fix Version/s: 10.0.0.Alpha3 (was: 10.0.0.Alpha2) > Connection Reauthentication and Security Propagation > ---------------------------------------------------- > > Key: WFLY-447 > URL: https://issues.jboss.org/browse/WFLY-447 > Project: WildFly > Issue Type: Task > Components: EJB, Remoting, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: authentication_service > Fix For: 10.0.0.Alpha3 > > > This task is a top level task to coordinate the addition of support for switching to different security identities on an existing connection over Remoting. > This is to predominantly cover two major scenarios: - > - Clients using a single connection but require different calls to be executed as different users, in this case the client has the information required to start a new authentication as a different user. > - Server to server communication where the first server has already authenticated a remote user - for this scenario the first server needs a way to tell the second server what identity to run the call as. > The following document is building up the requirements and design considerations and decisions: - > https://community.jboss.org/wiki/ConnectionRe-AuthenticationAndSecurityPr... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-483) Allow more control over authentication for server to server communication through remote-outbound-connection

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-483?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-483: ------------------------------ Fix Version/s: 10.0.0.Alpha3 (was: 10.0.0.Alpha2) > Allow more control over authentication for server to server communication through remote-outbound-connection > ------------------------------------------------------------------------------------------------------------ > > Key: WFLY-483 > URL: https://issues.jboss.org/browse/WFLY-483 > Project: WildFly > Issue Type: Sub-task > Components: Remoting, Security > Reporter: jaikiran pai > Assignee: Darran Lofthouse > Labels: authentication_service > Fix For: 10.0.0.Alpha3 > > > Right now for server to server communication via a remote-outbound-connection, we expect a static username to be specified (along with the security realm). User applications which use this remote-outbound-connection, for example an EJB application, do not have much control over the user/pass information, since the username is static. This further acts a drawback since the username that's used to connect to the remote server will be used as the (application) user who invoked the EJB. > It would be good to allow more control over the authentication for the remote-outbound-connection. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1136) Common mechanism for all secure socket definitions

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-1136?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-1136: ------------------------------- Fix Version/s: 10.0.0.Alpha3 (was: 10.0.0.Alpha2) > Common mechanism for all secure socket definitions > -------------------------------------------------- > > Key: WFLY-1136 > URL: https://issues.jboss.org/browse/WFLY-1136 > Project: WildFly > Issue Type: Sub-task > Components: Domain Management, Security > Reporter: Brian Stansberry > Assignee: Darran Lofthouse > Fix For: 10.0.0.Alpha3 > > > This JIRA is based on feedback we received after the Andiamo BOF at JBoss World 2010: > >> The JAASSecurityDomain in my opinion should > >> handle all secure socket definitions. Mod-cluster currently does > >> not support JAASSecurityDomains. > I won't comment either way on whether JAASSecurityDomain is how we'll do this, but I definitely agree that a common mechanism should be used for all secure socket definitions. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-569) Implement an account lockout mechanism for domain management.

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-569?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-569: ------------------------------ Fix Version/s: 10.0.0.Alpha3 (was: 10.0.0.Alpha2) > Implement an account lockout mechanism for domain management. > ------------------------------------------------------------- > > Key: WFLY-569 > URL: https://issues.jboss.org/browse/WFLY-569 > Project: WildFly > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: Common_Authentication, Realm_Management, management_security, > Fix For: 10.0.0.Alpha3 > > > One issue to consider is that we are using realms to integrate with existing user stores so may not be able to update the remote store: - > - Consider an option to update the remote store if possible. > - If not cache a backlisted user until an admin unlocks that account > Before being implemented this feature will require further discussion, in additional to locking mechanisms for unlocking should also be considered and also the potentional for denail of service type attacks based on locking out the administrators. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-497) Infinispan thread pool injection

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-497?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-497: ------------------------------ Fix Version/s: 10.0.0.Alpha3 (was: 10.0.0.Alpha2) > Infinispan thread pool injection > -------------------------------- > > Key: WFLY-497 > URL: https://issues.jboss.org/browse/WFLY-497 > Project: WildFly > Issue Type: Sub-task > Components: Clustering > Reporter: David Lloyd > Assignee: Radoslav Husar > Fix For: 10.0.0.Alpha3 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-487) Verify audit implications and required APIs

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-487?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-487: ------------------------------ Fix Version/s: 10.0.0.Alpha3 (was: 10.0.0.Alpha2) > Verify audit implications and required APIs > ------------------------------------------- > > Key: WFLY-487 > URL: https://issues.jboss.org/browse/WFLY-487 > Project: WildFly > Issue Type: Sub-task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: authentication_service > Fix For: 10.0.0.Alpha3 > > > Auditing may be logging as the user that executes a request, if we have used a trust relationship for a request to be run as a different user we need to be able to track back to identify how the user for the request was selected. > i.e. If userA runs something as userB and does something bad we must be able to track back that it was userA making the overall request without userB getting the blame. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2387) CDI injection in entity listeners failing

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-2387?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-2387: ------------------------------- Fix Version/s: 10.0.0.Alpha3 (was: 10.0.0.Alpha2) > CDI injection in entity listeners failing > ----------------------------------------- > > Key: WFLY-2387 > URL: https://issues.jboss.org/browse/WFLY-2387 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, Class Loading, JPA / Hibernate > Affects Versions: 8.0.0.Beta1 > Reporter: Emond Papegaaij > Assignee: Scott Marlow > Fix For: 10.0.0.Alpha3 > > Attachments: TEST-org.jboss.as.test.integration.ee.injection.support.jpa.EntityListenerInjectionSupportTestCase.xml > > > When trying to use CDI injection in JPA entity listeners, deployment fails with the following exception: > {code} > 16:16:37,448 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 15) MSC000001: Failed to start service jboss.persistenceunit."inject-ear.ear#primary": org.jboss.msc.service.StartException in service jboss.persistenceunit."inject-ear.ear#primary": java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader@4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment. > at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169) > at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117) > at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25] > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3] > at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final] > Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader@4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment. > at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75) > at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:128) > at org.jboss.weld.Container.instance(Container.java:65) > at org.jboss.weld.manager.BeanManagerImpl.getBeans(BeanManagerImpl.java:563) > at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:90) > at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358) > at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369) > at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72) > at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60) > at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66) > at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) > at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64) > at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90) > at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:82) > at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:71) > at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory.buildListener(BeanManagerListenerFactory.java:57) > at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.resolveCallbacks(LegacyCallbackProcessor.java:168) > at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.processCallbacksForEntity(LegacyCallbackProcessor.java:71) > at org.hibernate.jpa.event.spi.JpaIntegrator.integrate(JpaIntegrator.java:150) > at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310) > at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837) > at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854) > at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847) > at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396) > at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846) > at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44) > at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151) > ... 8 more > {code} > I've created a small showcase of the problem: https://github.com/papegaaij/listener-injection -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1830) Wildfly High Availability Guide: Hibernate clustering write up

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-1830?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-1830: ------------------------------- Fix Version/s: 10.0.0.Alpha3 (was: 10.0.0.Alpha2) > Wildfly High Availability Guide: Hibernate clustering write up > -------------------------------------------------------------- > > Key: WFLY-1830 > URL: https://issues.jboss.org/browse/WFLY-1830 > Project: WildFly > Issue Type: Sub-task > Components: Clustering, Documentation > Reporter: Radoslav Husar > Assignee: Scott Marlow > Fix For: 10.0.0.Alpha3 > > > https://docs.jboss.org/author/display/WFLY8/Hibernate -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1598) Out of the box SSL - or shortly after.

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-1598?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-1598: ------------------------------- Fix Version/s: 10.0.0.Alpha3 (was: 10.0.0.Alpha2) > Out of the box SSL - or shortly after. > -------------------------------------- > > Key: WFLY-1598 > URL: https://issues.jboss.org/browse/WFLY-1598 > Project: WildFly > Issue Type: Sub-task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Labels: management_security,, management_sso > Fix For: 10.0.0.Alpha3 > > > There are various reasons that we do not support SSL/TLS out of the box e.g. > - If we ship a default keystore then everyone has access to the private key. > - Generating one on first boot we do not have sufficient information to generate it correctly, also the performance overhead. > This issue is to explorer other options to encourage their use and make it easier to configure. > As an example could the admin console detect a non encrypted connection and have an box that encourages the config along with a wizard like workflow to get it set up? -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 5 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2015