That is really cool, I'll have to take a closer look at fortress and it
looks like Apache Directory is picking up steam again (Apache DS was a
great tool, i'm looking forward to the updates)

One caution I have about this is, I'm not sure what percentage of users
will have the ability to update their LDAP servers (in or outside an
application).  So in my opinion anything requiring the 'ft' ObjectClasses
would have to be optional.

Keep us posted,
-Brian

On Tue, Aug 2, 2016 at 8:54 AM, Shawn McKinney <[email protected]> wrote:

>
> >
> > On Aug 1, 2016, at 5:19 PM, Brian Demers <[email protected]> wrote:
> >
> > I did something similar with Sonatype's Nexus a while back, the code has
> moved around a bit since then, but you can still fine it:
> https://github.com/sonatype/nexus-oss/blob/nexus-2.11.x/components/nexus-ldap-common/src/main/java/org/sonatype/security/ldap/realms/AbstractLdapAuthenticationRealm.java
> > NOTE: this code is EPL
>
> Thanks, I’ll have a look.
>
> >
> > On Aug 1, 2016, at 5:19 PM, Brian Demers <[email protected]> wrote:
> >
> > How are you planning on storing/querying permission ?
>
> Follow apache fortress' model.  It defines a data structure mapping of
> object->operation as a hierarchy with one-to-many relationship between them.
>
> http://directory.apache.org/fortress/gen-docs/latest/apidocs/org/apache/directory/fortress/core/model/Permission.html
>
> Here is schema for the two elements, permission object and operation:
>
> ## Fortress Permission Object Structural Object Class
> objectclass ( ftObId:2
>     NAME 'ftObject'
>     DESC 'Fortress Permission Object Class'
>     SUP organizationalunit
>     STRUCTURAL
>     MUST (
>         ftId $
>         ftObjNm
>         )
>     MAY (
>         ftType
>         )
>     )
>
> ## Fortress Permission Operation Structural Object Class
> objectclass ( ftObId:3
>     NAME 'ftOperation'
>     DESC 'Fortress Permission Operation Structural Object Class'
>     SUP organizationalrole
>     STRUCTURAL
>     MUST (
>         ftId $
>         ftPermName $
>         ftObjNm $
>         ftOpNm
>         )
>     MAY (
>         ftObjId $
>         ftRoles $
>         ftUsers $
>         ftType
>         )
>     )
>
> Below is example idif extract for:
> object name: com.mycompany.Page1
> op name: add
> object ids, 123, 456, 789
>
> The advantage is simplicity and performance.  In order to perform a single
> permission check, i.e. checkAccess, it requires a single ldap ‘read’
> operations.  To retrieve all permissions for a user, i.e.
> sessionPermissions, is done with a single ldap ‘search’ operation.
>
> The disadvantage is currently doesn’t support for wildcard definitions in
> operation name.  I’ll need to study the shiro model a bit more before I
> claim that it can be added to this model.
>
> dn: ftOpNm=Update, ftObjNm=com.mycompany.Page1, ou=Permissions, ou=RBAC,
> dc=e
>  xample,dc=com
> ftPermName: com.mycompany.Page1.Update
> ftObjNm: com.mycompany.Page1
> ftOpNm: Update
> ftRoles: PAGE1_123
> ftRoles: PAGE1_456
> ftRoles: PAGE1_789
> ftRoles: ROLE_DEMO2_SUPER_USER
> objectClass: top
> objectClass: organizationalRole
> objectClass: ftOperation
> objectClass: ftProperties
> objectClass: ftMods
> description: Permission for page1.update
> cn: com.mycompany.Page1.Update
> ftId: b9672dea-9091-4634-a739-1382f604ad40
>
> dn: ftObjId=123+ftOpNm=Add, ftObjNm=com.mycompany.Page1, ou=Permissions,
> ou=R
>  BAC, dc=example,dc=com
> ftRoles: PAGE1_123
> ftRoles: ROLE_DEMO2_SUPER_USER
> ftPermName: com.mycompany.Page1.Add
> objectClass: top
> objectClass: organizationalRole
> objectClass: ftOperation
> objectClass: ftProperties
> objectClass: ftMods
> ftOpNm: Add
> ftObjNm: com.mycompany.Page1
> ftId: f27f6094-55ac-47a5-9977-0aa315a68520
> cn: com.mycompany.Page1.Add
> ftObjId: 123
> description: Permission for page1.add on Customer record 123
>
> dn: ftObjId=456+ftOpNm=Add, ftObjNm=com.mycompany.Page1, ou=Permissions,
> ou=R
>  BAC, dc=example,dc=com
> ftRoles: PAGE1_456
> ftRoles: ROLE_DEMO2_SUPER_USER
> ftPermName: com.mycompany.Page1.Add
> objectClass: top
> objectClass: organizationalRole
> objectClass: ftOperation
> objectClass: ftProperties
> objectClass: ftMods
> ftOpNm: Add
> ftObjNm: com.mycompany.Page1
> ftId: 9e2a5ea1-330d-4883-8113-3008e7a12858
> cn: com.mycompany.Page1.Add
> ftObjId: 456
> description: Permission for page1.add on Customer record 456
>
> dn: ftObjId=789+ftOpNm=Add, ftObjNm=com.mycompany.Page1, ou=Permissions,
> ou=R
>  BAC, dc=example,dc=com
> ftRoles: PAGE1_789
> ftRoles: ROLE_DEMO2_SUPER_USER
> ftPermName: com.mycompany.Page1.Add
> objectClass: top
> objectClass: organizationalRole
> objectClass: ftOperation
> objectClass: ftProperties
> objectClass: ftMods
> ftOpNm: Add
> ftObjNm: com.mycompany.Page1
> ftId: 6fa2cab8-f83b-4efa-bd6b-f9de5a7bb871
> cn: com.mycompany.Page1.Add
> ftObjId: 789
> description: Permission for page1.add on Customer record 789
>
>
>

Reply via email to