October 2007 - jboss-dev-forums - Jboss List Archives

[Design of Security on JBoss] - Re: Bringing together an unified security view

by sohil.shah＠jboss.com

tom- what you are talking about at this point is the Identity Management Framework. As far as the ACL component is concerned (topic of discussion in this thread), it should be Identity Management Framework agnostic with ability to plugin different Identity Management implementations. Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097975#4097975 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4097975

17 years, 3 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Bringing together an unified security view

by tom.baeyens＠jboss.com

"julien(a)jboss.com" wrote : I understand that Seam can be leveraged for integrating software nicely, but it should not be a requirement for using it. | +1. seam should not be required to leverage the shared identity component. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097972#4097972 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4097972

17 years, 3 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Bringing together an unified security view

by tom.baeyens＠jboss.com

"mark.proctor(a)jboss.com" wrote : Portal already has a use case driven Identity component, so Julian's requirements and code should be taken into account. the current layering of the portal identity component is a no go for jbpm. Julien, correct me if I'm wrong. The problem is not in the model of the data. I think we can easily find a common datamodel. The problem is in the pluggability layer of the portal component. Portal defines a session facade interface that provides access to users and group objects. Those objects themselves don't expose relation getters. Instead, the session facade contains the methods for traversing the relations. The motivation for the ession facade approach is to have different implementations. One for DB with hibernate, one for LDAP and so on. >From jBPM perspective, what I would like is for the shared identity component to look like this: * a set of java classes with getters and setters also for the relation properties. * hibernate persistence for those classes * JSF UI components as building blocks to create a identity management console. Then portal can still leverage such a component as 1 implementation (the DB/hibernate impl) of their own identity abstraction interfaces. I don't think it is feasible in the short term to come up with an interface that suits all requirements and that can switch between DB, LDAP and maybe other stores like e.g. XML files. But I do think it is feasible to create 1 implementation of a DB-schema/Java objects/hibernate mappings that everyone can leverage, leaving the abstraction interfaces still to the individual projects. E.g. in our case, those abstraction interfaces are on a per-use-case basis: an assignment handler for assigning a task to a user or a set of candidates. and an email address resolver that converts user ids into email adresses. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097971#4097971 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4097971

17 years, 3 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Bringing together an unified security view

by julien＠jboss.com

I understand that Seam can be leveraged for integrating software nicely, but it should not be a requirement for using it. "anil.saldhana(a)jboss.com" wrote : Instance Based ACL Implementation | I talked to Scott about Seam Security and the instance based security that is important for Non-AS projects like Drools, Portal, jBPM and Seam. | | | There are two prominent projects that have tried to solve instance based security: | | 1) OSAccess from OpenSymphony [1] through [3] (A dead project now) | 2) Acegi Security for Spring [4] | | I also point you to an article on IBM Developer Works for differences between container authorization (typically RBAC) and Data Driven Authorization (Instance Based). | | What we will provide: | A simple library that does a mapping between roles structure (groups, nested roles etc) and instance based crud (bits representing CRUD). The key here is to keep it simple and fast. The library can have pluggable implementation strategies like hibernate, ldap, cache whatever. | | Integration for Drools, jBPM, Portal etc: | Scott feels that they should integrate via Seam (same opinion from Proctor) because Seam is AS agnostic. They can integrate with JBoss Security to play nice with JBAS. Seam can then make use of the ACL implementation to provide other integration faces to different containers (WS, WL etc). | | References: | OSAccess | [1] http://wiki.opensymphony.com/display/OS/OSAccess | [2] https://osaccess.dev.java.net/ | [3]http://osdir.com/ml/java.open-symphony.devel/2002-07/msg00035.html (Note: Steve Ebersole in the mail) | | Acegi Security For Spring | [4] http://www.acegisecurity.org/acegi-security/apidocs/index.html | Look at the packages: org.acegisecurity.acl, org.acegisecurity.acls and their subpackages | | Authorization Concepts and Solutions for J2EE Applications | [5]http://www.ibm.com/developerworks/websphere/library/techarticles/0607_i... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097965#4097965 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4097965

17 years, 3 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Bringing together an unified security view

by julien＠jboss.com

Some important points for portal (and maybe for others too) is the capability to query several domains and get descriptions - existing resources that are secured and that could be secured - existing actions - relationship between actions - capability to test security for a specified subject and not something based on thread local The bottom line is that we not only need to be able to do checks, we also need to be able to do runtime configuration of various aspects and build complete GUI for it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097963#4097963 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4097963

17 years, 3 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Bringing together an unified security view

by anil.saldhana＠jboss.com

Instance Based ACL Implementation I talked to Scott about Seam Security and the instance based security that is important for Non-AS projects like Drools, Portal, jBPM and Seam. There are two prominent projects that have tried to solve instance based security: 1) OSAccess from OpenSymphony [1] through [3] (A dead project now) 2) Acegi Security for Spring [4] I also point you to an article on IBM Developer Works for differences between container authorization (typically RBAC) and Data Driven Authorization (Instance Based). What we will provide: A simple library that does a mapping between roles structure (groups, nested roles etc) and instance based crud (bits representing CRUD). The key here is to keep it simple and fast. The library can have pluggable implementation strategies like hibernate, ldap, cache whatever. Integration for Drools, jBPM, Portal etc: Scott feels that they should integrate via Seam (same opinion from Proctor) because Seam is AS agnostic. They can integrate with JBoss Security to play nice with JBAS. Seam can then make use of the ACL implementation to provide other integration faces to different containers (WS, WL etc). References: OSAccess [1] http://wiki.opensymphony.com/display/OS/OSAccess [2] https://osaccess.dev.java.net/ [3]http://osdir.com/ml/java.open-symphony.devel/2002-07/msg00035.html (Note: Steve Ebersole in the mail) Acegi Security For Spring [4] http://www.acegisecurity.org/acegi-security/apidocs/index.html Look at the packages: org.acegisecurity.acl, org.acegisecurity.acls and their subpackages Authorization Concepts and Solutions for J2EE Applications [5]http://www.ibm.com/developerworks/websphere/library/techarticles/0607_i... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097956#4097956 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4097956

17 years, 3 months

1
0
0 / 0

[Design of Security on JBoss] - Re: SRP and SASL

by anil.saldhana＠jboss.com

Just to get on the same page, SASL does the pluggable transfer of authentication information between point A and point B. Then you can configure SASL providers to ensure the confidentiality of the transport and the mechanics of it. I am thinking that you will need a SRP based SASL provider. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097951#4097951 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4097951

17 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - NoSuchEjbException with SFSB buddy replication

by bstansberry＠jboss.com

Discussion related to http://jira.jboss.com/jira/browse/JBAS-4812 . Dominik found this issue when testing node failover with buddy replication. As commented on the case, testing with the latest build from the JBC 1.4.x branch resolved the issue. This indicates the problem was likely related to http://jira.jboss.com/jira/browse/JBCACHE-1194, which was a data gravitation problem that was causing sessions not to be found on failover. At this point I hink the key issue here is to try to understand why Dominik was seeing the problem even before he shut down any nodes. The JBCACHE-1194 issue is only an issue when a client fails over; before shutdown there shouldn't have been failovers. Perhaps there is a problem with SFSB server affinity? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097906#4097906 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4097906

17 years, 3 months

1
0
0 / 0

[Design of JBossCache] - Re: Locking tree before setting initial state

by vblagojevic＠jboss.com

There is a rather big conceptual FLUSH change in JGroups 2.6. In 2.6 we always allow unicasts messages to pass down through FLUSH.down() latch. Bela and I realized that virtual synchrony property is relevant only to multicast messages and that FLUSH should not be concerned with unicasts at all. This has potentially a big impact on JBCACHE-315. Lets reopen discussion. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097898#4097898 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4097898

17 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: metadata simplication

by adrian＠jboss.org

"bill.burke(a)jboss.com" wrote : BTW, puke like this is why I like the DOM approach so much better. XB seems way to inflexible and overbearing most of the time. I think the problem is that as the title suggests, this is metadata simplication instead of simplfication. ;-) Incidently, the reason the old DOM stuff doesn't work is because it merges at parse time meaning you can't recreate the original xml documents afterwards. There should never have been an "override", we discussed this last friday. It should be possible to override the whole of ejb-jar.xml with the jboss.xml (or annonations) in fact, the ejb-jar.xml should be optional :-) So the JBossXXXMetaData is the override. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097894#4097894 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4097894

17 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2007