[JBoss JIRA] (WFLY-421) Domain Mode JMX access through the HostController
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-421?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated WFLY-421:
----------------------------------
Fix Version/s: 10.0.0.Alpha1
(was: 9.0.0.CR1)
> 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.Alpha1
>
>
> 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)
11 years, 2 months
[JBoss JIRA] (WFLY-487) Verify audit implications and required APIs
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-487?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated WFLY-487:
----------------------------------
Fix Version/s: 10.0.0.Alpha1
(was: 9.0.0.CR1)
> 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.Alpha1
>
>
> 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)
11 years, 2 months
[JBoss JIRA] (WFLY-569) Implement an account lockout mechanism for domain management.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-569?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated WFLY-569:
----------------------------------
Fix Version/s: 10.0.0.Alpha1
(was: 9.0.0.CR1)
> 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.Alpha1
>
>
> 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)
11 years, 2 months
[JBoss JIRA] (WFLY-447) Connection Reauthentication and Security Propagation
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-447?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated WFLY-447:
----------------------------------
Fix Version/s: 10.0.0.Alpha1
(was: 9.0.0.CR1)
> 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.Alpha1
>
>
> 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)
11 years, 2 months