December 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (SECURITY-89) Fast ACL Implementation

by Anil Saldhana (JIRA)

Fast ACL Implementation ----------------------- Key: SECURITY-89 URL: http://jira.jboss.com/jira/browse/SECURITY-89 Project: JBoss Security and Identity Management Issue Type: Task Security Level: Public (Everyone can see) Components: ACL Reporter: Anil Saldhana Assigned To: Stefan Guilhen Fix For: 2.0.2.GA We need to implement a FAST ACL implementation to be used by the non JBAS projects such as JBoss Rules, Portal etc. The key here is performance. We basically have a tuple (key, CRUD) where key is an object instance. We need to devise some mechanism by which the projects can plug in their key (similar to hibernate primary key mapping). The ACL implementation should not assume any strategies, which need to be pluggable. The strategies can be Hibernate, Cache or ldap depending on user needs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

2
7
0 / 0

[JBoss JIRA] Created: (EJBTHREE-932) EJB3 deployer must have an option for dynamic queue / topic creation

by Carlo de Wolf (JIRA)

EJB3 deployer must have an option for dynamic queue / topic creation -------------------------------------------------------------------- Key: EJBTHREE-932 URL: http://jira.jboss.com/jira/browse/EJBTHREE-932 Project: EJB 3.0 Issue Type: Feature Request Reporter: Carlo de Wolf Fix For: EJB 3.0 RC11 - FD Currently when the MDB container can't find a queue it will always connect to ServerPeer and asks it to create one. Scott: Whether or not the ejb container creates destinations has to be a manageable, metadata driven policy. This is ultimately overridable by the managment layer/policy service as whether or not a given environment allows for dynamic creation of destinations is an admin policy decision. It has nothing to do with whether ejb3 and jbm exist in the same environment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
3
0 / 0

[JBoss JIRA] Created: (JBRULES-966) update(fact) in 2 rules dont check for other updated facts - a loop is created

by Felipe Piccolini (JIRA)

update(fact) in 2 rules dont check for other updated facts - a loop is created ------------------------------------------------------------------------------ Key: JBRULES-966 URL: http://jira.jboss.com/jira/browse/JBRULES-966 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Reteoo Affects Versions: 4.0.0.MR3 Environment: tested on eclipse 3.2, JBossRules 4.0MR3, OS Mac OSX 10.4.10 Reporter: Felipe Piccolini Assigned To: Mark Proctor When using update in 2 rules that update the same object... a loop is created even when trying to avoid the loop adding an extra condition to each rule inserting an ArrayList as a fact too, so each rule should not be evaluated again... //-------RULES----------------------------- package org.drools.test #list any import classes here. import java.util.List import java.util.ArrayList import cl.bluesoft.test.rules.Fact #declare any global variables here rule "test update A" salience 699 no-loop when $f : Fact($n: number > 0) $list: ArrayList( this excludes "key1") then System.out.println("A-fact number1:"+$f.getNumber()+" list 1:"+$list); $list.add("key1"); $f.setNumber($n + 1); update ($f); update ($list); System.out.println("A-fact number2:"+$f.getNumber()+" list 2:"+$list); end rule "test update B" salience 699 no-loop when $f : Fact($n: number > 1) $list: ArrayList( this excludes "key2") then System.out.println("B-fact number1:"+$f.getNumber()+" list 1:"+$list); $list.add("key2"); $f.setNumber($n + 1); update ($f); update ($list); System.out.println("B-fact number2:"+$f.getNumber()+" list 2:"+$list); end //-------FACT----------------------------- public class Fact implements Serializable { private static final long serialVersionUID = 331627137981862975L; private int number; public Fact(int number){ this.number = number; } public Fact(){ this(0); } /** * @return the number */ public int getNumber() { return number; } /** * @param number the number to set */ public void setNumber(int number) { this.number = number; } } //------TEST--------- public class TestUpdateFact implements Serializable { private static final long serialVersionUID = -574789596641083743L; /** * @param args */ public static void main(String[] args) { RuleBase ruleBase = RuleBaseFactory.newRuleBase(); Package pkg = builder.getPackage(); .... WorkingMemory session = ruleBase.getStatefulSession(); ...etc etc... List list = new ArrayList(); Fact fact1 = new Fact(1); session.insert(fact1 false); session.insert(list, false); session.fireAllRules(); session.dispose(); } } //--------OUTPUT------------ A-fact number1:1 list 1:[] A-fact number2:2 list 2:[key1] B-fact number1:2 list 1:[key1] B-fact number2:3 list 2:[key1, key2] A-fact number1:3 list 1:[key1, key2] A-fact number2:4 list 2:[key1, key2, key1] B-fact number1:4 list 1:[key1, key2, key1] B-fact number2:5 list 2:[key1, key2, key1, key2] A-fact number1:5 list 1:[key1, key2, key1, key2] A-fact number2:6 list 2:[key1, key2, key1, key2, key1] B-fact number1:6 list 1:[key1, key2, key1, key2, key1] B-fact number2:7 list 2:[key1, key2, key1, key2, key1, key2] A-fact number1:7 list 1:[key1, key2, key1, key2, key1, key2] A-fact number2:8 list 2:[key1, key2, key1, key2, key1, key2, key1] B-fact number1:8 list 1:[key1, key2, key1, key2, key1, key2, key1] .... for ever..... So a loop is created... only when I use update and both rules... condition about the list not containing "key1" and "key2" seems not properly chequed... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 11 months

3
4
0 / 0

[JBoss JIRA] Created: (JBAS-3858) Update tc6-cluster.aop to match the current configuration

by Brian Stansberry (JIRA)

Update tc6-cluster.aop to match the current configuration --------------------------------------------------------- Key: JBAS-3858 URL: http://jira.jboss.com/jira/browse/JBAS-3858 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Ben Wang Fix For: JBossAS-5.0.0.Beta1 The pojocache-aop.xml used in JBC 2.0 is quite different from what we have in tc6-cluster.aop. We need to sync up. We want to maintain support for the old Tomcat-specific interface markers as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 11 months

6
12
0 / 0

[JBoss JIRA] Created: (JBAS-4967) Extract setting of default clustering JBossWebMetaData from TomcatDeployer

by Brian Stansberry (JIRA)

Extract setting of default clustering JBossWebMetaData from TomcatDeployer -------------------------------------------------------------------------- Key: JBAS-4967 URL: http://jira.jboss.com/jira/browse/JBAS-4967 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering, Web (Tomcat) service Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.Beta3 Don't use TomcatDeployer as an xml-to-JBossWebMetaData pass-through for the default clustering metadata. Initially I'm going to break this out just by creating a separate deployer for it. Real solution is to have some analogue to conf/web.xml and conf/standardjboss.xml where all the default jboss-web.xml values get set. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 11 months

1
5
0 / 0

[JBoss JIRA] Created: (JBAS-5039) Consider adding a conf/jboss-web.xml for all jboss-web.xml defaults

by Brian Stansberry (JIRA)

Consider adding a conf/jboss-web.xml for all jboss-web.xml defaults ------------------------------------------------------------------- Key: JBAS-5039 URL: http://jira.jboss.com/jira/browse/JBAS-5039 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Clustering, Web (Tomcat) service Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.CR1 A possible better solution for the parent issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 11 months

1
4
0 / 0

[JBoss JIRA] Created: (SECURITY-100) JBossAuthorizationManager needs to be threadsafe

by Anil Saldhana (JIRA)

JBossAuthorizationManager needs to be threadsafe ------------------------------------------------ Key: SECURITY-100 URL: http://jira.jboss.com/jira/browse/SECURITY-100 Project: JBoss Security and Identity Management Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JBossSX Affects Versions: 2.0.2-BETA Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: 2.0.2.GA Ensure JBossAuthorizationManager is threadsafe. Maybe AuthorizationContext has to become local to the authorize method or use an AtomicReference or bring the thread safety inside the AuthorizationContext class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 11 months

1
4
0 / 0

[JBoss JIRA] Created: (SECURITY-88) Refactor JaasSecurityManager into JBossAuthenticationManager

by Anil Saldhana (JIRA)

Refactor JaasSecurityManager into JBossAuthenticationManager ------------------------------------------------------------ Key: SECURITY-88 URL: http://jira.jboss.com/jira/browse/SECURITY-88 Project: JBoss Security and Identity Management Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.0.1.GA Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: 2.0.2.GA The code that exists in JaasSecurityManager needs to be pulled into a generic delegate in JBossSX such that the JaasSecurityManager in the AS security integration as well as the default AuthenticationManager can reuse. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 11 months

1
4
0 / 0

[JBoss JIRA] Created: (SECURITY-50) XACML EJB Layer: Role Reference Checks

by Anil Saldhana (JIRA)

XACML EJB Layer: Role Reference Checks -------------------------------------- Key: SECURITY-50 URL: http://jira.jboss.com/jira/browse/SECURITY-50 Project: JBoss Security and Identity Management Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JBossSX Affects Versions: 2.0.0.BETA Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: 2.0.1 Provide a mechanism to do EJBContext.isCallerInRole checks when xacml is enabled. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 11 months

1
3
0 / 0

[JBoss JIRA] Created: (SECURITY-29) Validate Jacc Policy Module handles all run-as scenarios

by Anil Saldhana (JIRA)

Validate Jacc Policy Module handles all run-as scenarios -------------------------------------------------------- Key: SECURITY-29 URL: http://jira.jboss.com/jira/browse/SECURITY-29 Project: JBoss Security and Identity Management Issue Type: Task Security Level: Public (Everyone can see) Components: JBossSX Affects Versions: 2.0.0.BETA Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: 2.0 With the roles being added to the security context via the mapping framework (for example), there may be cases where in run-as scenarios may not be adequately tested with the new Jacc authorization stuff. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 11 months

1
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2007