[JBoss JIRA] (DROOLS-2902) Link Scenario grid header cells with expression builder component
by Daniele Zonca (JIRA)
Daniele Zonca created DROOLS-2902:
-------------------------------------
Summary: Link Scenario grid header cells with expression builder component
Key: DROOLS-2902
URL: https://issues.jboss.org/browse/DROOLS-2902
Project: Drools
Issue Type: Task
Components: Scenario Simulation and Testing
Reporter: Daniele Zonca
Assignee: Gabriele Cardosi
When the user click on a cell of the header of the Scenario Grid, the right panel has to open and show the linked field from the expression builder and the opposite: when the user selects a value in the expression builder component the mapping has to be updated.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2901) Implement a recursive expression builder component
by Daniele Zonca (JIRA)
Daniele Zonca created DROOLS-2901:
-------------------------------------
Summary: Implement a recursive expression builder component
Key: DROOLS-2901
URL: https://issues.jboss.org/browse/DROOLS-2901
Project: Drools
Issue Type: Task
Components: Scenario Simulation and Testing
Reporter: Daniele Zonca
Assignee: Gabriele Cardosi
Add logic/behaviour to the static expression builder component:
1. Support infinite number of nested levels
2. Load data from DMO
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2900) Implement an expression builder component
by Daniele Zonca (JIRA)
Daniele Zonca created DROOLS-2900:
-------------------------------------
Summary: Implement an expression builder component
Key: DROOLS-2900
URL: https://issues.jboss.org/browse/DROOLS-2900
Project: Drools
Issue Type: Task
Components: Scenario Simulation and Testing
Reporter: Daniele Zonca
Assignee: Gabriele Cardosi
Implement a static expression builder component using HTML/CSS proposed in this ticket DROOLS-2784
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (SECURITY-719) request.getRemoteUser() returns invalid username on EAP 6.0.1.ER4.2
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/SECURITY-719?page=com.atlassian.jira.plug... ]
Darran Lofthouse updated SECURITY-719:
--------------------------------------
Fix Version/s: (was: Negotiation_2_2_2)
> request.getRemoteUser() returns invalid username on EAP 6.0.1.ER4.2
> -------------------------------------------------------------------
>
> Key: SECURITY-719
> URL: https://issues.jboss.org/browse/SECURITY-719
> Project: PicketBox
> Issue Type: Feature Request
> Components: Negotiation
> Affects Versions: Negotiation_2_2_1
> Environment: EAP 6.0.1.ER4.2
> SPNEGO setup with Kerberos
> Kerberos user: demo(a)LOCAL.NETWORK
> Reporter: Marek Posolda
>
> It seems that JBoss negotiation 2.2.1.Final doesn't work correctly on EAP 6.0.1.ER4.2. I am able to reproduce issue with SecuredServlet from negotiation toolkit.
> I logged in through SPNEGO (Kerberos) and in SecuredServlet, I am seeing those outputs:
> request.getUserPrincipal() returns principal with name "demo(a)LOCAL.NETWORK" -> OK
> request.getRemoteUser() returns something like "dPC0cG6NhAUi88tSbvQar59M_1357729358922" -> FAILURE!!!
> SecurityContextAssociation.getSecurityContext().getSubjectInfo().getIdentities().next() also returns "dPC0cG6NhAUi88tSbvQar59M_1357729358922" => FAILURE!!!
> Note that JBoss Negotiation 2.2.1.Final works correctly on JBoss AS 7.1.3 but it failed only on EAP 6.0.1.ER4.2. The reason is not related to Negotiation itself, but due to changes in behaviour in related libraries like jboss-as-web and picketbox-infinispan.
> In NegotiationAuthenticator the call to JBossWebRealm:
> principal = realm.authenticate(username, (String) null);
> now returns JBossGenericPrincipal with username taken from calling username. So it's something like "dPC0cG6NhAUi88tSbvQar59M_1357729358922" as calling username is only placeholder computed from sessionId and system time.
> Previously the username was taken from principal of JAAS authenticated user, which correctly returned "demo(a)LOCAL.NETWORK".
> So the bug seems to be due to changes in JBossWebRealm and maybe also picketbox classes like JBossCachedAuthenticationManager (seeing that cache key is now also calling username instead of username of authenticated principal).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (SECURITY-721) SPNEGO fallback to FORM based login has issues with user roles
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/SECURITY-721?page=com.atlassian.jira.plug... ]
Darran Lofthouse reassigned SECURITY-721:
-----------------------------------------
Assignee: (was: Darran Lofthouse)
> SPNEGO fallback to FORM based login has issues with user roles
> --------------------------------------------------------------
>
> Key: SECURITY-721
> URL: https://issues.jboss.org/browse/SECURITY-721
> Project: PicketBox
> Issue Type: Bug
> Components: Negotiation
> Affects Versions: Negotiation_2_2_1
> Reporter: Tom Fonteyne
>
> A standard setup of EAP 6.0.1 (containing nego 2.2.1) for SPNEGO with FORM fallover has issues in the third set of the toolkit tests.
> 10:54:47,378 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/jnt-eap6].[Secured]] (http-orac.usersys.redhat.com/10.33.1.221:8080-2) Servlet.service() for servlet Secured threw exception: java.lang.NullPointerException
> at org.jboss.security.negotiation.toolkit.SecuredServlet.doGet(SecuredServlet.java:88) [classes:]
> The failing line being:
> List<Role> roles = info.getRoles().getRoles();
> I back ported the extra lines from the toolkit to the one meant for EAP 5.x and there the above line works fine.
> The fact that the servlet is called does mean that JBoss received the correct roles, hence it's not clear whether that particular toolkit line being any issue for the general public.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (SECURITY-741) Spnego fallback with LDAP login modul does does not authorize properly
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/SECURITY-741?page=com.atlassian.jira.plug... ]
Darran Lofthouse reassigned SECURITY-741:
-----------------------------------------
Assignee: (was: Darran Lofthouse)
> Spnego fallback with LDAP login modul does does not authorize properly
> ----------------------------------------------------------------------
>
> Key: SECURITY-741
> URL: https://issues.jboss.org/browse/SECURITY-741
> Project: PicketBox
> Issue Type: Feature Request
> Components: Negotiation
> Affects Versions: PicketBox_4_0_14.Final
> Environment: Windows 2008
> AS 7.1.3
> Reporter: L D
>
> When using LDAP fallback mechanism with SPNEGO looks that Authorization always fails.
> Users are getting 403 message.
> When I setup same login modules to work in only Form authentication (without Spnego) or only SPNEGO (without fallback) everything is working.
> In server logs everything looks OK – user is authenticated but web application throwing 403 exception.
> 12:50:16,560 TRACE [org.jboss.security] (http-whofr836w33/172.29.60.93:8080-1) PBOX000201: End isValid, result = true
> 12:50:16,560 TRACE [org.jboss.as.web.security] (http-whofr836w33/172.29.60.93:8080-1) User: ld is authenticated
> 12:50:16,564 TRACE [org.jboss.as.web.security] (http-whofr836w33/172.29.60.93:8080-1) End invoke, caller=null
> 12:50:16,565 TRACE [org.jboss.security] (http-whofr836w33/172.29.60.93:8080-1) PBOX000354: Setting security roles ThreadLocal: null
> 12:50:16,567 TRACE [org.jboss.as.web.security] (http-whofr836w33/172.29.60.93:8080-1) Begin invoke, caller=null
> 12:50:16,567 TRACE [org.jboss.as.web.security] (http-whofr836w33/172.29.60.93:8080-1) Restoring principal info from cache
> 12:50:16,567 TRACE [org.jboss.security.negotiation.NegotiationAuthenticator] (http-whofr836w33/172.29.60.93:8080-1) Authenticating user
> 12:50:16,567 TRACE [org.jboss.security.negotiation.NegotiationAuthenticator] (http-whofr836w33/172.29.60.93:8080-1) Already authenticated 'ld'
> 12:50:16,567 TRACE [org.jboss.as.web.security] (http-whofr836w33/172.29.60.93:8080-1) hasRole:RealmBase says:false::Authz framework says:true:final=false
> 12:50:16,568 TRACE [org.jboss.as.web.security] (http-whofr836w33/172.29.60.93:8080-1) hasResourcePermission:RealmBase says:false::Authz framework says:true:final=false
> 12:50:16,568 TRACE [org.jboss.as.web.security] (http-whofr836w33/172.29.60.93:8080-1) End invoke, caller=null
> Example of standalone.xml
> <security-domain name="host" cache-type="default">
> <authentication>
> <login-module code="com.sun.security.auth.module.Krb5LoginModule" flag="required">
> <module-option name="debug" value="true"/>
> <module-option name="principal" value="HTTP/xxx"/>
> <module-option name="storeKey" value="true"/>
> <module-option name="useKeyTab" value="true"/>
> <module-option name="doNotPrompt" value="true"/>
> <module-option name="keyTab" value="D:/path to keytab.keytab"/>
> </login-module>
> </authentication>
> </security-domain>
> <security-domain name="SPNEGO" cache-type="default">
> <authentication>
> <login-module code="SPNEGO" flag="requisite">
> <module-option name="password-stacking" value="useFirstPass"/>
> <module-option name="serverSecurityDomain" value="host"/>
> <module-option name="debug" value="true"/>
> <module-option name="usernamePasswordDomain" value="fallback"/>
> </login-module>
> <login-module code="AdvancedAdLdap" flag="sufficient">
> <module-option name="bindAuthentication" value="GSSAPI"/>
> <module-option name="password-stacking" value="useFirstPass"/>
> <module-option name="jaasSecurityDomain" value="host"/>
> <module-option name="debug" value="true"/>
> <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
> <module-option name="java.naming.provider.url" value="ldap://xxx:389"/>
> <module-option name="bindDN" value="xxx"/>
> <module-option name="bindCredential" value="xxx"/>
> <module-option name="baseCtxDN" value="OU=xxx,DC=xx,DC=xxx,DC=xx"/>
> <module-option name="baseFilter" value="(userPrincipalName={0})"/>
> <module-option name="rolesCtxDN" value="OU=Production,OU=xxx,OU=xxx,DC=xxx,DC=xxx,DC=xx"/>
> <module-option name="roleFilter" value="(member={1})"/>
> <module-option name="roleAttributeID" value="accountNameHistory"/>
> <module-option name="roleNameAttributeID" value="cn"/>
> <module-option name="roleAttributeIsDN" value="false"/>
> <module-option name="throwValidateError" value="true"/>
> <module-option name="searchScope" value="SUBTREE_SCOPE"/>
> <module-option name="allowEmptyPasswords" value="false"/>
> <module-option name="java.naming.referral" value="follow"/>
> <module-option name="realmName" value="SPNEGO"/>
> </login-module>
> </authentication>
> </security-domain>
> <security-domain name="fallback" cache-type="default">
> <authentication>
> <login-module code="org.jboss.security.auth.spi.LdapExtLoginModule" flag="sufficient">
> <module-option name="bindAuthentication" value="GSSAPI"/>
> <module-option name="password-stacking" value="useFirstPass"/>
> <module-option name="debug" value="true"/>
> <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
> <module-option name="java.naming.provider.url" value="ldap://xxx:389"/>
> <module-option name="bindDN" value="xxx"/>
> <module-option name="bindCredential" value="xxx"/>
> <module-option name="baseCtxDN" value=" OU=xxx,DC=xx,DC=xxx,DC=xx "/>
> <module-option name="baseFilter" value="(sAMAccountName={0})"/>
> <module-option name="rolesCtxDN" value=" OU=Production,OU=xxx,OU=xxx,DC=xxx,DC=xxx,DC=xx "/>
> <module-option name="roleFilter" value="(member={1})"/>
> <module-option name="roleAttributeID" value="accountNameHistory"/>
> <module-option name="roleNameAttributeID" value="cn"/>
> <module-option name="roleAttributeIsDN" value="false"/>
> <module-option name="throwValidateError" value="true"/>
> <module-option name="searchScope" value="SUBTREE_SCOPE"/>
> <module-option name="allowEmptyPasswords" value="false"/>
> <module-option name="java.naming.referral" value="follow"/>
> <module-option name="removeRealmFromPrincipal" value="true"/>
> <module-option name="realmName" value="SPNEGO"/>
> </login-module>
> </authentication>
> </security-domain>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (SECURITY-719) request.getRemoteUser() returns invalid username on EAP 6.0.1.ER4.2
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/SECURITY-719?page=com.atlassian.jira.plug... ]
Darran Lofthouse reassigned SECURITY-719:
-----------------------------------------
Assignee: (was: Darran Lofthouse)
> request.getRemoteUser() returns invalid username on EAP 6.0.1.ER4.2
> -------------------------------------------------------------------
>
> Key: SECURITY-719
> URL: https://issues.jboss.org/browse/SECURITY-719
> Project: PicketBox
> Issue Type: Feature Request
> Components: Negotiation
> Affects Versions: Negotiation_2_2_1
> Environment: EAP 6.0.1.ER4.2
> SPNEGO setup with Kerberos
> Kerberos user: demo(a)LOCAL.NETWORK
> Reporter: Marek Posolda
>
> It seems that JBoss negotiation 2.2.1.Final doesn't work correctly on EAP 6.0.1.ER4.2. I am able to reproduce issue with SecuredServlet from negotiation toolkit.
> I logged in through SPNEGO (Kerberos) and in SecuredServlet, I am seeing those outputs:
> request.getUserPrincipal() returns principal with name "demo(a)LOCAL.NETWORK" -> OK
> request.getRemoteUser() returns something like "dPC0cG6NhAUi88tSbvQar59M_1357729358922" -> FAILURE!!!
> SecurityContextAssociation.getSecurityContext().getSubjectInfo().getIdentities().next() also returns "dPC0cG6NhAUi88tSbvQar59M_1357729358922" => FAILURE!!!
> Note that JBoss Negotiation 2.2.1.Final works correctly on JBoss AS 7.1.3 but it failed only on EAP 6.0.1.ER4.2. The reason is not related to Negotiation itself, but due to changes in behaviour in related libraries like jboss-as-web and picketbox-infinispan.
> In NegotiationAuthenticator the call to JBossWebRealm:
> principal = realm.authenticate(username, (String) null);
> now returns JBossGenericPrincipal with username taken from calling username. So it's something like "dPC0cG6NhAUi88tSbvQar59M_1357729358922" as calling username is only placeholder computed from sessionId and system time.
> Previously the username was taken from principal of JAAS authenticated user, which correctly returned "demo(a)LOCAL.NETWORK".
> So the bug seems to be due to changes in JBossWebRealm and maybe also picketbox classes like JBossCachedAuthenticationManager (seeing that cache key is now also calling username instead of username of authenticated principal).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (SECURITY-768) EJBContext Principal is null except on the first access where HTTP request principal is Ok
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/SECURITY-768?page=com.atlassian.jira.plug... ]
Darran Lofthouse reassigned SECURITY-768:
-----------------------------------------
Assignee: (was: Darran Lofthouse)
> EJBContext Principal is null except on the first access where HTTP request principal is Ok
> ------------------------------------------------------------------------------------------
>
> Key: SECURITY-768
> URL: https://issues.jboss.org/browse/SECURITY-768
> Project: PicketBox
> Issue Type: Bug
> Components: Negotiation
> Affects Versions: Negotiation_2.1.1
> Environment: JBoss 4.2.3.GA
> Jboss Security Negotiation 2.1.1.GA
> J2EE 5
> Reporter: Paulo Silva
> Attachments: login-config-fragment.txt
>
>
> I have a standard J2EE application (EAR) with a WAR and EJB.
> I'm using JSP and servlets to communicate with my EJB3.
> The EJB are protected using standard annotations like @RolesAllowed(value = "user") with the EJB having a "@SecurityDomain("blankTest")".
> SPNEGO LoginModule is configured as attached (standard configuration).
> When I call my JSP and it prints "request.getUserPrincipal();" the Principal is always returned as expected.
> When I call my EJB and print "sessionContext.getCallerPrincipal().toString()" the Principal is OK in the first access (when SPNEGO authentication occurs) but subsequent calls always return the principal as 'guest' (my unauthenticatedIdentity).
> When using a standard form LoginModule everything works OK.
> It seems some kind of "cache" is being lost.
> I tested many jboss-negotiation versions for compatibility for jboss 4.2.3 and the latest one that works is 2.1.1.GA and that version shows this problem. Version 2.0.4.GA works OK.
> I tracked down the offending code to "NegotiationAuthenticator.java" and the code that was introduced on SECURITY-129. If I remove the "setNext" method at the end of the class and the DelegationCredentialManager class, it also solves the problem, proving that code is the culprit of the bug. revision 113259 of the file works OK where 113267 starts showing the bug.
> It seems that code is still present on most recent versions of Jboss-negotiation but maybe that only causes problems in jboss 4.2.3?
> I only tested this in that jboss-as version.
> I can provide more details as I can understand the problem very well. I just can't understand what that piece of code does and why it causes this bug :)
> This is really a major bug as everything related to EJB security doesn't work as the principal isn't correct there...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months