New LDAP Realm Proposal

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

New LDAP Realm Proposal

Shawn McKinney
Hello,

I am thinking about creating a new LDAP realm for Shiro that has the following features:

1. usage of Apache LDAP API (rather than JNDI)
2. capability to perform permission based checks
3. capability for role based checks
4. declarative syntax for mapping to a variety of LDAP schemas
5. compatibility with any LDAPv3 impls including OpenLDAP, Apache Directory Server, ActiveDirectory, etc

But before I get started I wanted to gauge interest from the Shiro user community.  If the idea takes hold, I will likely create under my github account, and if all goes well, will contribute back to this community.

The value proposition is to have a fully functioning LDAP realm available for those in need.

WDYT?

Shawn
Reply | Threaded
Open this post in threaded view
|

Re: New LDAP Realm Proposal

David Jencks
What is the “Apache LDAP API” you mention in (1)?  Something you’re going to write for this realm or something that already exists somewhere else?

thanks
david jencks

> On Aug 1, 2016, at 2:21 PM, Shawn McKinney <[hidden email]> wrote:
>
> Hello,
>
> I am thinking about creating a new LDAP realm for Shiro that has the following features:
>
> 1. usage of Apache LDAP API (rather than JNDI)
> 2. capability to perform permission based checks
> 3. capability for role based checks
> 4. declarative syntax for mapping to a variety of LDAP schemas
> 5. compatibility with any LDAPv3 impls including OpenLDAP, Apache Directory Server, ActiveDirectory, etc
>
> But before I get started I wanted to gauge interest from the Shiro user community.  If the idea takes hold, I will likely create under my github account, and if all goes well, will contribute back to this community.
>
> The value proposition is to have a fully functioning LDAP realm available for those in need.
>
> WDYT?
>
> Shawn

Reply | Threaded
Open this post in threaded view
|

Re: New LDAP Realm Proposal

Brian Demers
I'm interested in a few of these, specifically #4, as I've seen a my share of users struggle to configure LDAP, especially when venturing outside of one of the more common schemas.

#3 naturally falls with #4 

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

How are you planning on storing/querying permission ?

On Mon, Aug 1, 2016 at 5:34 PM, David Jencks <[hidden email]> wrote:
What is the “Apache LDAP API” you mention in (1)?  Something you’re going to write for this realm or something that already exists somewhere else?

thanks
david jencks

> On Aug 1, 2016, at 2:21 PM, Shawn McKinney <[hidden email]> wrote:
>
> Hello,
>
> I am thinking about creating a new LDAP realm for Shiro that has the following features:
>
> 1. usage of Apache LDAP API (rather than JNDI)
> 2. capability to perform permission based checks
> 3. capability for role based checks
> 4. declarative syntax for mapping to a variety of LDAP schemas
> 5. compatibility with any LDAPv3 impls including OpenLDAP, Apache Directory Server, ActiveDirectory, etc
>
> But before I get started I wanted to gauge interest from the Shiro user community.  If the idea takes hold, I will likely create under my github account, and if all goes well, will contribute back to this community.
>
> The value proposition is to have a fully functioning LDAP realm available for those in need.
>
> WDYT?
>
> Shawn


Reply | Threaded
Open this post in threaded view
|

Re: New LDAP Realm Proposal

Shawn McKinney
In reply to this post by David Jencks

> On Aug 1, 2016, at 4:34 PM, David Jencks <[hidden email]> wrote:
>
> What is the “Apache LDAP API” you mention in (1)?  Something you’re going to write for this realm or something that already exists somewhere else?


http://directory.apache.org/api/
Reply | Threaded
Open this post in threaded view
|

Re: New LDAP Realm Proposal

Shawn McKinney
In reply to this post by Brian Demers

>
> On Aug 1, 2016, at 5:19 PM, Brian Demers <[hidden email]> 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 <[hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: New LDAP Realm Proposal

Brian Demers
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 <[hidden email]> wrote:

>
> On Aug 1, 2016, at 5:19 PM, Brian Demers <[hidden email]> 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 <[hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: New LDAP Realm Proposal

Shawn McKinney

> On Aug 2, 2016, at 9:04 AM, Brian Demers <[hidden email]> wrote:
>
> 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)
>

Yes the project has added many committers of late, along with new sub-projects like fortress (access management), kerby (kerberos implementation), and a SCIM component contributed by Penn State.  Eventually apacheds will be fitted with a new backend (mavibot), which will improve stability and performance.

>
> On Aug 2, 2016, at 9:04 AM, Brian Demers <[hidden email]> wrote:
>
> 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.
>

Good to know.  Ideally, the object class and attribute mappings are defined in shiro’s config file, enabling different object classes to be used.  It remains to be seen how practical that idea is.  i.e. there’s more to permission data structure usage than schema definitions.  In any case the ability to map to a variety of structures would be a work-in-progress.  The apache ldap api has capabilities here that may be useful.  I’ll start with the fortress model and go from there.

Shawn

Reply | Threaded
Open this post in threaded view
|

Re: New LDAP Realm Proposal

Pierre Smits
That's a great initiative, Shawn. 

Best regards,

Pierre

Op dinsdag 2 augustus 2016 heeft Shawn McKinney <[hidden email]> het volgende geschreven:

> On Aug 2, 2016, at 9:04 AM, Brian Demers <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;brian.demers@gmail.com&#39;)">brian.demers@...> wrote:
>
> 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)
>

Yes the project has added many committers of late, along with new sub-projects like fortress (access management), kerby (kerberos implementation), and a SCIM component contributed by Penn State.  Eventually apacheds will be fitted with a new backend (mavibot), which will improve stability and performance.

>
> On Aug 2, 2016, at 9:04 AM, Brian Demers <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;brian.demers@gmail.com&#39;)">brian.demers@...> wrote:
>
> 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.
>

Good to know.  Ideally, the object class and attribute mappings are defined in shiro’s config file, enabling different object classes to be used.  It remains to be seen how practical that idea is.  i.e. there’s more to permission data structure usage than schema definitions.  In any case the ability to map to a variety of structures would be a work-in-progress.  The apache ldap api has capabilities here that may be useful.  I’ll start with the fortress model and go from there.

Shawn



--
Pierre Smits
OFBiz based solutions & services

OFBiz Extensions Marketplace

Reply | Threaded
Open this post in threaded view
|

Re: New LDAP Realm Proposal

opticyclic
In reply to this post by Shawn McKinney
I think once #3 and #4 are done then #5 almost comes automatically as the user can add the various filters in the ini for the different uses cases.
However, there should be a useful set of defaults that work most of the time.
In that case, #5 could be implemented as a series of default search filters or one big search filter that included lots of OR statements to account for searching for all the common use cases.

I am for this new realm and I already posted on stackoverflow before seeing this thread
http://stackoverflow.com/questions/39679428/is-there-a-generic-way-to-search-for-ldap-groups-with-shiro

As you can see, I was disappointed to not find #3, 4, 5 already included in DefaultLdapRealm.

With that in mind, could you do it so that 3,4,5 are done in DefaultLdapRealm and then extend it to add #1 in the subclass?

That way most of the features are available by default and the subclass is an optional alternative that uses the Apache LDAP API instead of JNDI.

I haven't mentioned #2 as I'm not sure if that depends on the API or can be done with JNDI too.
Reply | Threaded
Open this post in threaded view
|

Re: New LDAP Realm Proposal

Brian Demers
I'm all for a improved LDAP realm.  The points in the stackoverflow posts are also valid.

Sonatype's Nexus did something similar with their LDAP realm. We had templates for common schemas and usage patterns, authentication only, AD, Posix with dynamic or without static groups, etc.

NOTE: The Nexus solution used an API that also supported writes, so something done in Shiro would not need to be as involved (I would guess)


If anyone wants to take this on send us a pull request!
-Brian

On Sun, Sep 25, 2016 at 7:55 PM, opticyclic <[hidden email]> wrote:
I think once #3 and #4 are done then #5 almost comes automatically as the
user can add the various filters in the ini for the different uses cases.
However, there should be a useful set of defaults that work most of the
time.
In that case, #5 could be implemented as a series of default search filters
or one big search filter that included lots of OR statements to account for
searching for all the common use cases.

I am for this new realm and I already posted on stackoverflow before seeing
this thread
http://stackoverflow.com/questions/39679428/is-there-a-generic-way-to-search-for-ldap-groups-with-shiro

As you can see, I was disappointed to not find #3, 4, 5 already included in
DefaultLdapRealm.

With that in mind, could you do it so that 3,4,5 are done in
DefaultLdapRealm and then extend it to add #1 in the subclass?

That way most of the features are available by default and the subclass is
an optional alternative that uses the Apache LDAP API instead of JNDI.

I haven't mentioned #2 as I'm not sure if that depends on the API or can be
done with JNDI too.



--
View this message in context: http://shiro-user.582556.n2.nabble.com/New-LDAP-Realm-Proposal-tp7581200p7581291.html
Sent from the Shiro User mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|

Re: New LDAP Realm Proposal

Shawn McKinney
I wanted to wait a bit to gauge community interest on this before spending a bunch of time on it.  It appears that it is there.  The other constraint is time, as in not enough of it.  I’d be open to a combined effort to speed thing up.

> On Sep 26, 2016, at 9:20 AM, Brian Demers <[hidden email]> wrote:
>
> I'm all for a improved LDAP realm.  The points in the stackoverflow posts are also valid.
>
> Sonatype's Nexus did something similar with their LDAP realm. We had templates for common schemas and usage patterns, authentication only, AD, Posix with dynamic or without static groups, etc.
> https://books.sonatype.com/nexus-book/reference/ldap-sect-user-group-mapping.html
>
> NOTE: The Nexus solution used an API that also supported writes, so something done in Shiro would not need to be as involved (I would guess)
>
>
> If anyone wants to take this on send us a pull request!
> -Brian
>
> On Sun, Sep 25, 2016 at 7:55 PM, opticyclic <[hidden email]> wrote:
> I think once #3 and #4 are done then #5 almost comes automatically as the
> user can add the various filters in the ini for the different uses cases.
> However, there should be a useful set of defaults that work most of the
> time.
> In that case, #5 could be implemented as a series of default search filters
> or one big search filter that included lots of OR statements to account for
> searching for all the common use cases.
>
> I am for this new realm and I already posted on stackoverflow before seeing
> this thread
> http://stackoverflow.com/questions/39679428/is-there-a-generic-way-to-search-for-ldap-groups-with-shiro
>
> As you can see, I was disappointed to not find #3, 4, 5 already included in
> DefaultLdapRealm.
>
> With that in mind, could you do it so that 3,4,5 are done in
> DefaultLdapRealm and then extend it to add #1 in the subclass?
>
> That way most of the features are available by default and the subclass is
> an optional alternative that uses the Apache LDAP API instead of JNDI.
>
> I haven't mentioned #2 as I'm not sure if that depends on the API or can be
> done with JNDI too.
>
>
>
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/New-LDAP-Realm-Proposal-tp7581200p7581291.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>

Reply | Threaded
Open this post in threaded view
|

Re: New LDAP Realm Proposal

opticyclic
If you post your fork where you are doing the work, I can pitch in a bit.
Reply | Threaded
Open this post in threaded view
|

Re: New LDAP Realm Proposal

Shawn McKinney

> On Sep 28, 2016, at 7:22 PM, opticyclic <[hidden email]> wrote:
>
> If you post your fork where you are doing the work, I can pitch in a bit.
>

Actually I’m counting on the other way around.  My inclination is to write the data access layer and let someone who is knowledgable of shiro’s framework do the rest.  Which is to say I can’t spare the time to develop expertise in how shiro works, but I can help where my skills are, java, ldap, rbac, to add permissions.

Shawn