March 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-462) Eliminate the threads subsystem

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-462?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-462: ------------------------------ Fix Version/s: 9.0.0.CR1 (was: 9.0.0.Beta1) > Eliminate the threads subsystem > ------------------------------- > > Key: WFLY-462 > URL: https://issues.jboss.org/browse/WFLY-462 > Project: WildFly > Issue Type: Task > Reporter: David Lloyd > Assignee: Tomaz Cerar > Fix For: 9.0.0.CR1 > > > The threads subsystem should be eliminated, and instead the individual consuming subsystems should utilize common code from the jboss-as-threads module to define and manage thread pools within their own configuration models. > Subtasks for affected subsystems. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-473) Get rid of external .index files

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-473?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-473: ------------------------------ Fix Version/s: 9.0.0.CR1 (was: 9.0.0.Beta1) > Get rid of external .index files > -------------------------------- > > Key: WFLY-473 > URL: https://issues.jboss.org/browse/WFLY-473 > Project: WildFly > Issue Type: Task > Components: Build System > Reporter: David Lloyd > Fix For: 9.0.0.CR1 > > > The external {{*.index}} files have become a problem for distribution. In 8 we should switch to using internal {{META-INF/PATHS.LIST}} files. These files should be embedded during build. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[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: 9.0.0.CR1 (was: 9.0.0.Beta1) > 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: 9.0.0.CR1 > > > 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.11#6341)

11 years, 1 month

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: 9.0.0.CR1 (was: 9.0.0.Beta1) > 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: 9.0.0.CR1 > > > 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.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-485) Review SecurityContext associations

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-485?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-485: ------------------------------ Fix Version/s: 9.0.0.CR1 (was: 9.0.0.Beta1) > Review SecurityContext associations > ------------------------------------ > > Key: WFLY-485 > URL: https://issues.jboss.org/browse/WFLY-485 > Project: WildFly > Issue Type: Sub-task > Components: Security > Reporter: Darran Lofthouse > Assignee: David Lloyd > Labels: Security_SPI > Fix For: 9.0.0.CR1 > > > We should re-review the approach we take for security context association within AS7 containers. > Back at the time of AS 3 it fairly reliable to assume a 1:1 mapping of thread and client with the incoming connection being allocated it's own thread, this is no longer automatically the case and different containers can use different threading models e.g. using Executors to handle asynchronous requests. > The problem with using a ThreadLocal approach is that every time a container diverges from the 1:1 mapping of thread and client that container needs to work around the issue of an invalid SecurityContext association. > One possibility is to pass responsibility for managing the context to the container although this then introduces the question of how it is passed from container to container. This issue needs to consider this further. > Also need to review further how the security context can be created at all entry points to the server and how it can be manually switched now that we use SASL on entry for remote calls we do now have the opportunity for equivalent behaviour at the entry point for both web and ejb type calls - in the past we only had this opportunity for web based calls and would only create a security context on entering the interceptors for the EJB calls. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-553) Allow for alternative access control providers to be plugged into management.

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-553?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-553: ------------------------------ Fix Version/s: 9.0.0.CR1 (was: 9.0.0.Beta1) > Allow for alternative access control providers to be plugged into management. > ----------------------------------------------------------------------------- > > Key: WFLY-553 > URL: https://issues.jboss.org/browse/WFLY-553 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: Authorization, Realm_Management > Fix For: 9.0.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

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: 9.0.0.CR1 (was: 9.0.0.Beta1) > 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: 9.0.0.CR1 > > > 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.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-904) The property AuthorizationManager is null exceptions and NPE on SimpleSecurityManager when connecting firstly from a remote client

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-904?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-904: ------------------------------ Fix Version/s: 9.0.0.CR1 (was: 9.0.0.Beta1) > The property AuthorizationManager is null exceptions and NPE on SimpleSecurityManager when connecting firstly from a remote client > ---------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-904 > URL: https://issues.jboss.org/browse/WFLY-904 > Project: WildFly > Issue Type: Bug > Components: Security > Environment: Eclipse Juno SR2 with JBoss Tools, Mac OS X, Sun JDK 6 > Reporter: Fernando Nasser > Assignee: Darran Lofthouse > Labels: eap6, investigation_required > Fix For: 9.0.0.CR1 > > Attachments: NPEinSimpleSecurityManager, PBOX000075, QSecuredEJB.jar, QSecuredEJB.zip, SecurityRelatedSettings > > > Description of problem: > If one tries and use security enabled EJBs from a remote client (authenticated connection) before connecting first from a servlet both a Server NPE and an erroneous exception are thrown. However, if one uses some servlet-based authentication first, the missing field is "primed" and from that point on the remote application can use the secure EJBs normally, proper Role authorization is checked and enforced etc. With absolutely no changes in configuration, code (incl. annotation) whatsoever. Any number of remote client connections will succeed until you restart the server. Then the errors are back, until you "prime" the Server by connecting using a Servlet. > More complete data is attached, but here are some info: > NPE is thrown at: > org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:394) > Bean method invocation fails with exceptions containing the message: > JBAS011048: Failed to construct component instance > I am using the "other" security context for testing. > I am running the Server in standalone mode. > When I say remote I mean not in the Server, but I am running my client from localhost. > Version-Release number of selected component (if applicable): Seen on EAP 6.1.0 alpha (apparently present on AS 7.1.1 as well). > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-782) DefaultAuthenticationCacheFactory should not use internal Infinispan classes

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-782?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-782: ------------------------------ Fix Version/s: 9.0.0.CR1 (was: 9.0.0.Beta1) > DefaultAuthenticationCacheFactory should not use internal Infinispan classes > ---------------------------------------------------------------------------- > > Key: WFLY-782 > URL: https://issues.jboss.org/browse/WFLY-782 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: NadirX > Assignee: Paul Ferraro > Fix For: 9.0.0.CR1 > > > The DefaultAuthenticationCacheFactory class (and the AuthenticationCacheEvictionListener class) use internal Infinispan classes which are subject to change without API stability guarantees. The code should be rewritten to use an Infinispan cache instead. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

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: 9.0.0.CR1 (was: 9.0.0.Beta1) > 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: 9.0.0.CR1 > > > 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.11#6341)

11 years, 1 month

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 March 2015