directory-fortress mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Pike <>
Subject Re: 1.0-RC41 Release
Date Thu, 10 Dec 2015 18:12:54 GMT
We had discussed the idea of a RoleOU, similar to a PermOU, which would be used by ARBAC and
eliminate the ARBAC role explosion problem. It would also give us an easy way to group roles
for a particular application together. What are your thoughts on that proposal?

----- Original Message -----
From: "Shawn McKinney" <>
Sent: Monday, December 7, 2015 4:25:08 PM
Subject: Re: 1.0-RC41 Release

> On Dec 7, 2015, at 2:34 PM, Jan Sindberg <> wrote:
> We are hard at work using the RC41. We probably haven't fetched changes for the last
three weeks. My hope is that what we currently use is fairly stable :-)

The fortress sub-projects have been pretty stable so I would expect upgrading to latest, i.e.
RC41 to go smoothly for you.  

> On Dec 7, 2015, at 2:34 PM, Jan Sindberg <> wrote:
> We are not very advanced in our usage.
> You are probably not thinking about getting Accel and Audit for ApacheDS as an option
within this x-mas month :-)

Unfortunately we’re not going to get audit/accel into apacheds by xmas but it could show
up under the tree by same time next year if we got some volunteers to work on it….  :-)

> On Dec 7, 2015, at 2:34 PM, Jan Sindberg <> wrote:
> On what "areas" would you like to hear opinions about "what needs to be in this very
next one"? (How can we help?)

There are so many areas that need work.  I can break these down into:

1. structure

There are discussions about combining the 4 sub-projects (core,realm,rest,web) into a single
repo but I am going to delay that for at least another release, until we get a better idea
of the best structure.  And yes that would be disruptive for upgrading.  Not convinced it
needs to happen (combining into one).

2. documentation

What needs to happen as part of the next release is to improve documentation.  Specifically:

a. configuration (you already mentioned this one)
b. openldap and apacheds quickstarts for debian, centos and window platforms.
c. documentation on more advanced use cases like RBAC1, RBAC2, RBAC3, and ARBAC usages.

I can provide these instructions into readme’s.  Need suggestions on what the best overall
documentation format should be going forward.

3. usage inside other systems

Need to integrate with other apps and systems like:

a. apache shiro (can wrap fortress apis)
b. spring and java ee security apis (again can wrap)
c. apis for other platforms like php, python
d. authN and authZ routines for apache web

For this task the accelerator functional model would be used.  That is the client would bind
using LDAPv3 extended protocol to drive the rbac system mgr apis for policy enforcement. 
There are currently examples of using Java, C and python though only the java client bindings
have been released.    


View raw message