May 2015 - jboss-jira - Jboss List Archives

[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)

8 years, 11 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)

8 years, 11 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)

8 years, 11 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)

8 years, 11 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)

8 years, 11 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)

8 years, 11 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)

8 years, 11 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)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2552) Undertow AuthenticationMechanism Configuration Overrides

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-2552?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-2552: ------------------------------- Fix Version/s: 10.0.0.Alpha3 (was: 10.0.0.Alpha2) > Undertow AuthenticationMechanism Configuration Overrides > -------------------------------------------------------- > > Key: WFLY-2552 > URL: https://issues.jboss.org/browse/WFLY-2552 > Project: WildFly > Issue Type: Task > Components: Web (Undertow) > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: web_security > Fix For: 10.0.0.Alpha3 > > > General article covering the security configuration for Undertow / WildFly: - > https://community.jboss.org/wiki/UndertowSecurityConfiguration -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2440) Thread pool AccessControlContext Propagation

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-2440?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-2440: ------------------------------- Fix Version/s: 10.0.0.Alpha3 (was: 10.0.0.Alpha2) > Thread pool AccessControlContext Propagation > -------------------------------------------- > > Key: WFLY-2440 > URL: https://issues.jboss.org/browse/WFLY-2440 > Project: WildFly > Issue Type: Task > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 10.0.0.Alpha3 > > > A decision was made within Java that newly created threads should inherit the access control context of their creator. > In general this was justified on the basis that if you are creating a thread you want it to inherit the permissions you already have. > Once we introduce thread pooling that logic no longer makes as much sense and there is not the same relationship between the thread that triggers it's creation and the long term life of that thread. > This may affect components outside of WildFly but I am raising it here as a top level task. > Should also note that JBoss Threads does already have some protection built in if a security manager is in use but there are times the AccessControlContext will be used without a security manager so more control is required. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2015