[JBoss JIRA] (WFLY-442) Review of AccessController and PrivilegedAction use across AS7
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-442?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-442:
------------------------------
Fix Version/s: 10.0.0.Alpha3
(was: 10.0.0.Alpha2)
> Review of AccessController and PrivilegedAction use across AS7
> --------------------------------------------------------------
>
> Key: WFLY-442
> URL: https://issues.jboss.org/browse/WFLY-442
> Project: WildFly
> Issue Type: Task
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: investigation_required
> Fix For: 10.0.0.Alpha3
>
>
> The following needs reviewing across AS7: -
> - On demand instantiation of PrivilegedActions where singletons would suffice (Consider frequency of calls, gc may be preferable).
> - Use of AccessController even though there is no SecurityManager set.
> - Code duplication, in every case I have seen so far the code is the same regardless of if PRIVILEGED or NON_PRIVILEGED
> - Utility methods with visibility too high.
> - In depth review of the other methods, i.e. if the first thing a public method does is set the class loader based on a parameter passed in it could be used badly - it may even be a justification for that method to NOT use a PrivilegedAction.
> - Code that requires to be executed using a PrivilegedAction should also be double checked that it is not doing too much as the identity of the caller.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-431) Revisit enforcement of required file system permissions.
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-431?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-431:
------------------------------
Fix Version/s: 10.0.0.Alpha3
(was: 10.0.0.Alpha2)
> Revisit enforcement of required file system permissions.
> --------------------------------------------------------
>
> Key: WFLY-431
> URL: https://issues.jboss.org/browse/WFLY-431
> Project: WildFly
> Issue Type: Task
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: management_security,
> Fix For: 10.0.0.Alpha3
>
>
> Now that AS8 has moved to Java 7 we can re-visit the level of control we have over file system permissions, this can be from taking more control of the local authentication mechanism to ensure incorrect permissions are not inherited to verifying sensitive configuration files are not world readable.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-421) Domain Mode JMX access through the HostController
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-421?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-421:
------------------------------
Fix Version/s: 10.0.0.Alpha3
(was: 10.0.0.Alpha2)
> Domain Mode JMX access through the HostController
> -------------------------------------------------
>
> Key: WFLY-421
> URL: https://issues.jboss.org/browse/WFLY-421
> Project: WildFly
> Issue Type: Task
> Components: JMX, Remoting
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: JMX, investigation_required
> Fix For: 10.0.0.Alpha3
>
>
> This task is first to review if this should be considered.
> At the moment access to JMX is provided through the remoting connector of each AS instance - this task is to consider if we should actually make it available through the host controller with the host controller acting as a proxy.
> The main motivation being to separate management and app traffic.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[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, 11 months
[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, 11 months
[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, 11 months
[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, 11 months
[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, 11 months