[JBoss JIRA] (WFLY-482) Domain Management - Enable silent authentication using Kerberos
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-482?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated WFLY-482:
----------------------------------
Labels: Common_Authentication Kerberos, management_security, (was: Common_Authentication Kerberos, web_security)
> Domain Management - Enable silent authentication using Kerberos
> ---------------------------------------------------------------
>
> Key: WFLY-482
> URL: https://issues.jboss.org/browse/WFLY-482
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: Common_Authentication, Kerberos,, management_security,
> Fix For: 9.0.0.CR1
>
>
> It should be possible for users to authenticate for domain management using Kerberos.
> Over the HTTP interface this will be SPNEGO, for the Native connection we use SASL so can use GSSAPI
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (WFLY-483) Allow more control over authentication for server to server communication through remote-outbound-connection
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-483?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated WFLY-483:
----------------------------------
Labels: authentication_service (was: )
> 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
> Security Level: Public(Everyone can see)
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (WFLY-484) Re visit authentication tokens
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-484?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated WFLY-484:
----------------------------------
Labels: Common_Authentication management_security, management_sso (was: Common_Authentication)
> Re visit authentication tokens
> ------------------------------
>
> Key: WFLY-484
> URL: https://issues.jboss.org/browse/WFLY-484
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: Common_Authentication, management_security,, management_sso
> Fix For: 9.0.0.CR1
>
>
> We had previously considered authentication tokens for the realm secured interfaces, this issue is just to track re-considering them again.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 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:
----------------------------------
Labels: authentication_service (was: )
> Verify audit implications and required APIs
> -------------------------------------------
>
> Key: WFLY-487
> URL: https://issues.jboss.org/browse/WFLY-487
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (WFLY-486) Implement Trust for users requesting to run as a different user.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-486?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated WFLY-486:
----------------------------------
Labels: authentication_service (was: )
> Implement Trust for users requesting to run as a different user.
> ----------------------------------------------------------------
>
> Key: WFLY-486
> URL: https://issues.jboss.org/browse/WFLY-486
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: Remoting, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: authentication_service
> Fix For: 9.0.0.CR1
>
>
> Where SASL is used for authentication users can request to authenticate as themselves but to be authorized to connect to the server as a different user.
> A couple of examples where this could be used: -
> - A user granting access to another user to log into their account.
> - A user with two levels of access e.g. normal and admin and requesting they have admin level access.
> Another area we are looking to use this feature is where one server connects to another server but want to be able to run requests on the remote server using the identity of a specified user.
> This Jira issue is to enhance the security realms to allow for trust permissions to be defined - initially this will be local to a single realm but will subsequently be opened up to work across different realms.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (WFLY-1011) there should be some notification when modcluster is available but not working because Advertise is silently failing.
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-1011?page=com.atlassian.jira.plugin.... ]
Radoslav Husar reassigned WFLY-1011:
------------------------------------
Assignee: Radoslav Husar (was: Jean-Frederic Clere)
> there should be some notification when modcluster is available but not working because Advertise is silently failing.
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1011
> URL: https://issues.jboss.org/browse/WFLY-1011
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Clustering
> Environment: standalone server with modcluster and simple load balance test.
> Reporter: Simeon Pinder
> Assignee: Radoslav Husar
> Labels: rhq
>
> Run standalone server with -c standalone-ha.xml and mod_cluster configured on the same box for a simple load balancing test. Modcluster is not able to detect the as7 instance without explicitly setting the Profiles > ModCluster > Proxies> ProxyList property in console to the ServerAdvertise value from httpd.conf. There should be some sort of indication in the UI or in the server logs when Advertise functionality is not working or fails to work.
> Additionally the documentation for modcluster setup and FAQ should be updated to include this note for those troubleshooting their modcluster setups.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (WFLY-563) Better integration of service based ServerAuthenticationProviders
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-563?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated WFLY-563:
----------------------------------
Fix Version/s: (was: 9.0.0.CR1)
> Better integration of service based ServerAuthenticationProviders
> -----------------------------------------------------------------
>
> Key: WFLY-563
> URL: https://issues.jboss.org/browse/WFLY-563
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Domain Management, Remoting, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: Remoting_Management
>
> The security configuration of Remoting within AS7 is based on supplying three things: -
> - The ServerAuthenticationProvider to obtain mechanism specific CallbackHanlders
> - The OptionMap to control the security mechanisms made available / mandated.
> - Possibly an initialised SSLContext for XnioSsl if SSL is being enabled.
> For domain management the capabilities of the backing realm are used to define the security offered i.e. if we have no SSL configuration we can not enable SSL, if the backing store can not return the plain text passwords we can not enable DIGEST. This has been achieved so far by using an intermediary service to define the configuration based on capabilities alone.
> This task it to take it one step further and allow this intermediary to be defined within the Remoting subsystem and maybe an equivalent for pure domain management to act as both a intermediary to define configuration based on the realm and also to allow additional configuration overrides. i.e. we need to support the additional SASL options available and SSL options available - this will somehow need to be merged / validated with the realm capabilities e.g. if a Realm is incompatible with Digest a user can not force the use of Digest.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (WFLY-534) Make realms fully manageable through domain.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-534?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated WFLY-534:
----------------------------------
Fix Version/s: (was: 9.0.0.CR1)
> Make realms fully manageable through domain.
> --------------------------------------------
>
> Key: WFLY-534
> URL: https://issues.jboss.org/browse/WFLY-534
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: Realm_Management
>
> For the management interfaces we are making use of realms backed by CallbackHandlers for the authenticators / mechanisms.
> This Jira is to look at making the contents of these realms manageable where possible e.g. : -
> - Definition of users
> - Modifications to users / password resets
> - Role memberships
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (WFLY-534) Make realms fully manageable through domain.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-534?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated WFLY-534:
----------------------------------
Labels: Realm_Management management_security, management_sso (was: Realm_Management)
> Make realms fully manageable through domain.
> --------------------------------------------
>
> Key: WFLY-534
> URL: https://issues.jboss.org/browse/WFLY-534
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: Realm_Management, management_security,, management_sso
>
> For the management interfaces we are making use of realms backed by CallbackHandlers for the authenticators / mechanisms.
> This Jira is to look at making the contents of these realms manageable where possible e.g. : -
> - Definition of users
> - Modifications to users / password resets
> - Role memberships
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months