[JBoss JIRA] (WFLY-3040) Missing modules
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3040?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reassigned WFLY-3040:
---------------------------------
Assignee: Tomaz Cerar (was: Thomas Diesler)
> Missing modules
> ---------------
>
> Key: WFLY-3040
> URL: https://issues.jboss.org/browse/WFLY-3040
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Build System
> Affects Versions: 8.0.0.Final
> Environment: Windows 64 bits
> Reporter: David Cabillic
> Assignee: Tomaz Cerar
>
> I listed modules with links to missing ones :
> || module || missing module ||
> | org.infinispan.client.hotrod | com.google.protobuf |
> | org.jboss.as.aggregate | org.jboss.as.managed-beans |
> | org.jboss.genericjms | org.jboss.genericjms.provider |
--
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
[JBoss JIRA] (WFLY-3048) "Local" authentication fails when LDAP is used for ManagementRealm
by Matt Jensen (JIRA)
Matt Jensen created WFLY-3048:
---------------------------------
Summary: "Local" authentication fails when LDAP is used for ManagementRealm
Key: WFLY-3048
URL: https://issues.jboss.org/browse/WFLY-3048
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Security
Affects Versions: 8.0.0.Final
Environment: Ubuntu 13.04, Xeon-based VPS
Reporter: Matt Jensen
Assignee: Darran Lofthouse
When LDAP is used for authentication in ManagementRealm, "local" authentication, which is enabled in configuration for the realm, appears to stop working.
I have configured my ManagementRealm to use LDAP for authentication of remote clients. However, I also need to allow local authentication without a username and password, for when jboss-cli is invoked from the command line on the server. This is needed in order for the wildfly-init-debian.sh script to shut down the server. I have configured the ManagementRealm as follows:
<security-realm name="ManagementRealm">
<authentication>
<local default-user="$local" />
<ldap connection="..." base-dn="ou=accounts,dc=..." recursive="false">
...
</ldap>
</authentication>
<authorization map-groups-to-roles="false">
<ldap connection="...">
...
</ldap>
</authorization>
</security-realm>
I left out most of the LDAP configuration because I don't think it is important for this issue. LDAP authentication works fine for remote clients. In fact, it works fine for local clients as well--when I invoke jboss-cli with LDAP authentication enabled, it prompts for a username and password; if I enter a valid combination from the LDAP directory, jboss-cli connects successfully and executes its command.
The problem is that I need it to NOT prompt for a username and password when jboss-cli is invoked locally. Which, I believe, is how things are supposed to work when "local" authentication is also enabled; it just doesn't work that way when LDAP is enabled for the same realm.
If I comment out the <ldap .../> element in <authentication> for the realm, local authentication starts working again. I can invoke jboss-cli locally and the command is carried out without a username and password prompt. Re-enable LDAP, with no other configuration changes, and again it flips back to requiring a username and password.
I have tried replacing "$local" in the @default-user element of the <local> element with a valid name from the LDAP directory, both as a simple username and as a full DN, and jboss-cli still prompts for a username and password.
The modification date on the [tmp/auth] directory changes when I run jboss-cli with LDAP in place and get the username/password prompt, so it appears that the client is putting a token in there to try to use local authentication. The server just never picks it up.
The documentation specifically mentions that <local/> should work along with <ldap/> here:
https://docs.jboss.org/author/display/WFLY8/Security+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
[JBoss JIRA] (JBEE-149) Patch Taglibs Bug 33934
by Kevin Formsma (JIRA)
Kevin Formsma created JBEE-149:
----------------------------------
Summary: Patch Taglibs Bug 33934
Key: JBEE-149
URL: https://issues.jboss.org/browse/JBEE-149
Project: JBoss JavaEE Spec APIs
Issue Type: Bug
Components: jboss-jstl-api
Affects Versions: jboss-jstl-api_1.2_spec-1.0.5.Final
Reporter: Kevin Formsma
Assignee: Shelly McGowan
Taglibs fixed a bug where SetTag would retain references to the target object, causing pooled SetTag instances to have much higher memory usage when the target object is large. When using many web threads in JBoss 7.2.2, our heap grows due to these objects being associated to pooled SetTags.
https://issues.apache.org/bugzilla/show_bug.cgi?id=33934
Can this patch be fixed in the jboss fork of taglibs as well?
--
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
[JBoss JIRA] (WFLY-3040) Missing modules
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3040?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-3040:
----------------------------------------
The org.jboss.genericjms.provider module needs to be provided by the user, containing the necessary binaries provided by the provider (e.g. Tibco) they wish to integrate.
> Missing modules
> ---------------
>
> Key: WFLY-3040
> URL: https://issues.jboss.org/browse/WFLY-3040
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Build System
> Affects Versions: 8.0.0.Final
> Environment: Windows 64 bits
> Reporter: David Cabillic
> Assignee: Thomas Diesler
>
> I listed modules with links to missing ones :
> || module || missing module ||
> | org.infinispan.client.hotrod | com.google.protobuf |
> | org.jboss.as.aggregate | org.jboss.as.managed-beans |
> | org.jboss.genericjms | org.jboss.genericjms.provider |
--
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
[JBoss JIRA] (WFLY-2581) Provide API for use by ejb-security-interceptors quick start.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-2581?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-2581:
-----------------------------------
Description:
The quick start accesses the currently authenticated user, unfortunately this representation is with a bunch of internal implementation classes.
• org.jboss.as.domain.management.security.RealmUser.
• org.jboss.as.security.remoting.RemotingContext.
• org.jboss.as.controller.security.SubjectUserInfo
The first problem is the RemotingContext, we use it internally to associate the remoting connection with the thread processing the request, the only reason we really use it is to obtain the identity of the user associated with the connection, we may be better simplifying this down to just associate a simple ConnectionSecurityContext with the thread instead.
Secondly once we have used the identity associated with the connection we clear the association, this is probably the wrong way round and instead we should be setting something to say we have used the identity.
The SubjectUserInfo is essentially the ConnectionSecurityContext I mention above, we need a simple representation of this that can be used.
Finally there is RealmUser, we should also add RealmGroup - these two classes just need to be in their own public module or inherit from something that is.
As a closing point should these be marked as deprecated? Security services are being re-worked in WildFly and this whole quick start is just an alternative solution to the new services.
was:The quick start accesses the currently authenticated user, unfortunately this representation is with a bunch of internal implementation classes.
> Provide API for use by ejb-security-interceptors quick start.
> -------------------------------------------------------------
>
> Key: WFLY-2581
> URL: https://issues.jboss.org/browse/WFLY-2581
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 8.0.1.Final
>
>
> The quick start accesses the currently authenticated user, unfortunately this representation is with a bunch of internal implementation classes.
> • org.jboss.as.domain.management.security.RealmUser.
> • org.jboss.as.security.remoting.RemotingContext.
> • org.jboss.as.controller.security.SubjectUserInfo
> The first problem is the RemotingContext, we use it internally to associate the remoting connection with the thread processing the request, the only reason we really use it is to obtain the identity of the user associated with the connection, we may be better simplifying this down to just associate a simple ConnectionSecurityContext with the thread instead.
> Secondly once we have used the identity associated with the connection we clear the association, this is probably the wrong way round and instead we should be setting something to say we have used the identity.
> The SubjectUserInfo is essentially the ConnectionSecurityContext I mention above, we need a simple representation of this that can be used.
> Finally there is RealmUser, we should also add RealmGroup - these two classes just need to be in their own public module or inherit from something that is.
> As a closing point should these be marked as deprecated? Security services are being re-worked in WildFly and this whole quick start is just an alternative solution to the new 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
[JBoss JIRA] (WFLY-3040) Missing modules
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3040?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-3040:
------------------------------
Component/s: Build System
(was: OSGi)
> Missing modules
> ---------------
>
> Key: WFLY-3040
> URL: https://issues.jboss.org/browse/WFLY-3040
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Build System
> Affects Versions: 8.0.0.Final
> Environment: Windows 64 bits
> Reporter: David Cabillic
> Assignee: Thomas Diesler
>
> I listed modules with links to missing ones :
> || module || missing module ||
> | org.infinispan.client.hotrod | com.google.protobuf |
> | org.jboss.as.aggregate | org.jboss.as.managed-beans |
> | org.jboss.genericjms | org.jboss.genericjms.provider |
--
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
[JBoss JIRA] (WFLY-3046) Not possible change the object store type from hornetq to jdbc via cli commands
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3046?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-3046:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1038993
> Not possible change the object store type from hornetq to jdbc via cli commands
> -------------------------------------------------------------------------------
>
> Key: WFLY-3046
> URL: https://issues.jboss.org/browse/WFLY-3046
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transactions
> Affects Versions: 8.0.0.Final
> Reporter: Ivo Studensky
> Assignee: Ivo Studensky
>
> When you have set the object store to be type of hornetq and then you change your mind to set it for jdbc object store the jboss-cli permits this operation but no change is propagated to model and XML file.
> How to reproduce:
> # ./bin/standalone.xml (start eap 6.2.0.GA)
> # ./bin/jboss-cli.sh -c (connect to running eap)
> # /subsystem=transactions:write-attribute(name=use-hornetq-store, value=true)
> # :reload# /subsystem=transactions/log-store=log-store:read-attribute(name=type)# /subsystem=transactions:write-attribute(name=use-jdbc-store, value=true)# :reload
> # /subsystem=transactions/log-store=log-store:read-attribute(name=type)
> The object store stays to be set to hornetq and no change happens in the standalone.xml file.
--
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