[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: 8.0.0.Final
(was: 8.0.0.CR1)
> 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
> Fix For: 8.0.0.Final
>
>
> 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, 7 months
[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: 8.0.0.Final
(was: 8.0.0.CR1)
> Review SecurityContext associations
> ------------------------------------
>
> Key: WFLY-485
> URL: https://issues.jboss.org/browse/WFLY-485
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: David Lloyd
> Labels: Security_SPI
> Fix For: 8.0.0.Final
>
>
> 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 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, 7 months
[JBoss JIRA] (WFLY-490) Domain Management Role Based Access Control
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-490?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-490:
------------------------------
Fix Version/s: 8.0.0.Final
(was: 8.0.0.CR1)
> Domain Management Role Based Access Control
> -------------------------------------------
>
> Key: WFLY-490
> URL: https://issues.jboss.org/browse/WFLY-490
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Labels: Authorization
> Fix For: 8.0.0.Final
>
>
> Implement some coarse permissions for domain operations. Possibly allowing a break down for subsystem, profile, server, server-group - maybe read - write - execute.
> Also consider confidentiality in exchange e.g. Can read metrics over http but must use https to add new server.
--
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, 7 months
[JBoss JIRA] (WFLY-486) Implement Trust for users requesting to run as a different user.
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-486?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-486:
------------------------------
Fix Version/s: 8.0.0.Final
(was: 8.0.0.CR1)
> 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
> Fix For: 8.0.0.Final
>
>
> 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, 7 months
[JBoss JIRA] (WFLY-543) Provide an operation to request service status report after server has been started
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-543?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-543:
------------------------------
Fix Version/s: 8.0.0.Final
(was: 8.0.0.CR1)
> Provide an operation to request service status report after server has been started
> -------------------------------------------------------------------------------------
>
> Key: WFLY-543
> URL: https://issues.jboss.org/browse/WFLY-543
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Heiko Braun
> Labels: console_prio
> Fix For: 8.0.0.Final
>
>
> For proper healthcare it would beneficial if I could verify the server status after it has been started. I.e. to catch these, which currently only appear in the server log:
> [Server:server-three] 17:48:26,636 INFO [org.jboss.as.server] (MSC service thread 1-2) Service status report
> [Server:server-three] New missing/unsatisfied dependencies:
> [Server:server-three] service jboss.binding.http2 (missing)
> [Server:server-three]
> [Server:server-three] 17:48:26,636 ERROR [org.jboss.as] (MSC service thread 1-4) JBoss AS 7.0.0.Beta4-SNAPSHOT "(TBD)" started (with errors) in 3893ms - Started 101 of 149 services (1 services failed or missing dependencies, 47 services are passive or on-demand)
--
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, 7 months
[JBoss JIRA] (WFLY-768) Caused by: javax.sound.sampled.UnsupportedAudioFileException: could not get audio input stream from input stream
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-768?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-768:
------------------------------
Fix Version/s: 8.0.0.Final
(was: 8.0.0.CR1)
> Caused by: javax.sound.sampled.UnsupportedAudioFileException: could not get audio input stream from input stream
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-768
> URL: https://issues.jboss.org/browse/WFLY-768
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Server
> Environment: windows 7 jdk1.6,eclipse juno,
> Reporter: raky k
> Assignee: Jason Greene
> Labels: UnsupportedAudioFileException
> Fix For: 8.0.0.Final
>
>
> The application is working fine in the tomcat when deployed in the Jboss server it does not recognizes wav format and throws error Caused by: javax.sound.sampled.UnsupportedAudioFileException: could not get audio input stream from input stream
> The application is open source and can be found
> http://sourceforge.net/projects/simplecaptcha/files/simplecaptcha-1.2-j2e...
> i have done below changes but still no luck. ( as advised on https://community.jboss.org/thread/197517 )
> "
> Darran is right, it requires to edit the modules/sun/jdk/main/modules.xml and add an entry for com.sun.media.
>
> Moreover, copy the following files to modules/sun/jdk/main/service-loader-resources/META-INF/services/
> javax.sound.sampled.spi.AudioFileReader
> javax.sound.sampled.spi.AudioFileWriter
> javax.sound.sampled.spi.FormatConversionProvider
> javax.sound.sampled.spi.MixerProvider
> These files can be found inside /jre/lib/resources.jar of JDK, under /META-INF/services/ "
--
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, 7 months