Fortress best pratices?

[何嘉权 <ji...@9am.ai>]

Hi mighty Fortress,

My team is evaluating how Fortress could fit into our product as an access
control system.

We've gone through the major official documents, set up a demo with the
REST enmasse as well as the Web commander, and played with it a little bit.
But we cannot find any best practice when it comes to our business
requirements.

We've multiple tenants with organizations of users, and organizations of
resources. According to our understanding of Fortress, we've ideas:

- Multiple tenants should be well supported as documented.
- User organization could be implemented with Fortress's role organization.
- Resource organization could be implemented with Fortress's perm object
organization.

But then questions pop up and we fail to get any clue:

- By adding a new tenant, there's no OOTB RESTful API. [1]
- User role inheritance is pretty powerful, but why do we still need Group
that doesn't have inheritance support? [2]
- If one tenant has 1,000 of resources, and each of them has READ/UPDATE
permission, is it expected to have 2,000 different permission objects in
Fortress?

Thanks for any advice.

[1]
https://github.com/apache/directory-fortress-core/blob/master/README-MULTITENANCY.md
[2] https://directory.apache.org/fortress/gen-docs/latest/apidocs/

Re: Fortress best pratices?

[何嘉权 <ji...@9am.ai>]

Thank you Shawn for all the information!

On Mon, Sep 16, 2019 at 12:22 AM Shawn McKinney <sm...@apache.org>
wrote:

> Hi,
>
> Just to add a bit to what Yudhi said…
>
> >> 1. We are wondering if Fortress provides any REST api to add new
> tenants.
> >> Or should we implement one?
>
>
> No REST API currently.  The data structure of a tenant is just an LDAP
> entry of type organizationalUnit,
>
> Fortress refers to these organizationalUnit entries ‘containers’, a common
> LDAP term.  i.e. containers of something.  That something could be entries
> or other containers.
>
> There exist add, delete, data access methods to do this:
>
>
> https://directory.apache.org/fortress/gen-docs/latest/apidocs/org/apache/directory/fortress/core/impl/OrganizationalUnitP.html
>
> It’s easy to wrap this API with REST but I’ve hesitated because no one’s
> asked for it.  However, the APIs referenced above are public and could be
> called from another (Java) program.  The hard part would be how the APIs
> are used. What I mean, again a tenant is a container.  Below that container
> are more containers, ou=People, ou=Roles, etc.
> Creating a new tenant would have to call the
>
> add(OrganizationalUnit orgUnit) method many times.
>
> So, the maybe not so easy part is creating a higher level method, that
> understands the concept of a fortress tenant and create all of the entries
> in the tree so the user doesn’t have to.
>
> addTenant( Tenant tenant )
>
> This higher level method does not exist currently but it would be an
> interesting conversation of what one would look like.  If a clear idea
> emerges perhaps it can be implemented in the future.
>
> >>>> - User role inheritance is pretty powerful, but why do we still need
> Group
>
> As Yudhi pointed out Fortress is a framework for RBAC.  But, it does other
> things as well.  For example, traditional LDAP groups can be created with
> its APIs for usage in situations where RBAC enforcements doesn’t apply,
> like traditional Unix envs and legacy Web systems.
>
> There’s another, more compelling use case: trusted logon.  This occurs
> inside environments where the end user of the app isn’t known, but the
> user's type or role is.  Think Oauth2, SAML or OpenStack[1] type logins.
> Here, we can create sessions using a group, which maps to the type of user
> logging into the system:
>
>
> https://directory.apache.org/fortress/gen-docs/latest/apidocs/org/apache/directory/fortress/core/AccessMgr.html#createSession-org.apache.directory.fortress.core.model.Group-
>
> The group that gets passed in, was assigned one or more roles.  When
> createSession is called with a group, its corresponding roles are activated
> into the session, and checkAccess can be used.
>
> But, these are special use cases that don’t apply in many situations so
> that using the group object is often not needed.
>
> Good questions.  Keep them coming.
>
> —
> Shawn
>
> [1] FC-144 - Ability to assign groups to roles:
> https://issues.apache.org/jira/browse/FC-144
>
>
> > On Sep 15, 2019, at 7:14 AM, Yudhi Karunia Surtan <yu...@apache.org>
> wrote:
> >
> > Hi 何嘉权,
> >
> > 1. Currently i don't think it is possible to add tenant, but that should
> be
> > if you try to use ldap library directly. As long as you know the
> directory
> > structure layout and ldap schema, that is possible.
> > 2. Ya, currently i'm not using any Group for my current project
> > implementation yet.(I'm using fortress from version 1.0.0-RC39)
> > 3. It should be ok to have many permissions records, because later you
> just
> > need to check using
> >
> https://directory.apache.org/fortress/gen-docs/latest/apidocs/org/apache/directory/fortress/core/AccessMgr.html
> > at
> > checkAccess method.
> >
> > In my opinion, fortress is giving you the framework of how rbac works. In
> > the end, you are the one that need to define and fit it with your use
> case.
> > Currently, I worked at blibli (http://www.blibli.com), one of the
> biggest
> > e-commerce company in Indonesia.
> > I'm using fortress and Apereo CAS to as the authentication and
> > authorization of the most back-office management applications for all the
> > microservices and successfully centralize the access management for all
> > employees.
> > Hopefully with my testimonial you can try to use it too, it just need
> > little creativity to try to fit it with your use case since fortress is
> the
> > implementation of Role-Based Access Control ANSI INCITS 359-2004.
> >
> > Thanks
> >
> > Regards,
> >
> >
> > Yudhi Karunia Surtan
> > --------------------------------------
> > https://github.com/yudhik
> >
> >
> > On Sun, Sep 15, 2019 at 1:02 PM 何嘉权 <ji...@9amai> wrote:
> >
> >> Hi Yudhi,
> >>
> >> Thanks for replying and sorry for my ambiguity.
> >>
> >> We’re not implementing a second fortress. We’re learning to use it
> >> correctly to avoid going to a wrong direction.
> >>
> >> 1. We are wondering if Fortress provides any REST api to add new
> tenants.
> >> Or should we implement one?
> >> 2. Do you mean you’re not using groups?
> >> 3. Surprised to know about this!
> >>
> >> On Sun, Sep 15, 2019 at 1:39 PM Yudhi Karunia Surtan <
> yudhiks@apache.org>
> >> wrote:
> >>
> >>> Hi jiaquan,
> >>>
> >>>
> >>> 1. What is ootb mean?
> >>> 2. Currently I'm not using it.
> >>> 3. Yes, since it is a whitelist of permission. Currently, I think I
> have
> >>> more than 2000 perms at my current implementation at my company.
> >>>
> >>> Anyway, what do you mean by best practice here? Is it about correctness
> >>> how you implement it? Or how to exactly using fortress?
> >>>
> >>> Sorry for my bad English.
> >>>
> >>>
> >>> Regards,
> >>>
> >>>
> >>> Yudhi Karunia Surtan
> >>>
> >>>
> >>>
> >>>
> >>> On Sun, Sep 15, 2019, 10:18 何嘉权 <ji...@9am.ai> wrote:
> >>>
> >>>> Hi mighty Fortress,
> >>>>
> >>>> My team is evaluating how Fortress could fit into our product as an
> >>>> access
> >>>> control system.
> >>>>
> >>>> We've gone through the major official documents, set up a demo with
> the
> >>>> REST enmasse as well as the Web commander, and played with it a little
> >>>> bit.
> >>>> But we cannot find any best practice when it comes to our business
> >>>> requirements.
> >>>>
> >>>> We've multiple tenants with organizations of users, and organizations
> of
> >>>> resources. According to our understanding of Fortress, we've ideas:
> >>>>
> >>>> - Multiple tenants should be well supported as documented.
> >>>> - User organization could be implemented with Fortress's role
> >>>> organization.
> >>>> - Resource organization could be implemented with Fortress's perm
> object
> >>>> organization.
> >>>>
> >>>> But then questions pop up and we fail to get any clue:
> >>>>
> >>>> - By adding a new tenant, there's no OOTB RESTful API. [1]
> >>>> - User role inheritance is pretty powerful, but why do we still need
> >>>> Group
> >>>> that doesn't have inheritance support? [2]
> >>>> - If one tenant has 1,000 of resources, and each of them has
> READ/UPDATE
> >>>> permission, is it expected to have 2,000 different permission objects
> in
> >>>> Fortress?
> >>>>
> >>>> Thanks for any advice.
> >>>>
> >>>> [1]
> >>>>
> >>>>
> https://github.com/apache/directory-fortress-core/blob/master/README-MULTITENANCY.md
> >>>> [2] https://directory.apache.org/fortress/gen-docs/latest/apidocs/
> >>>>
> >>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fortress-unsubscribe@directory.apache.org
> For additional commands, e-mail: fortress-help@directory.apache.org
>
>

Re: Fortress best pratices?

[Shawn McKinney <sm...@apache.org>]

Hi,

Just to add a bit to what Yudhi said…

>> 1. We are wondering if Fortress provides any REST api to add new tenants.
>> Or should we implement one?


No REST API currently.  The data structure of a tenant is just an LDAP entry of type organizationalUnit, 

Fortress refers to these organizationalUnit entries ‘containers’, a common LDAP term.  i.e. containers of something.  That something could be entries or other containers.

There exist add, delete, data access methods to do this:

https://directory.apache.org/fortress/gen-docs/latest/apidocs/org/apache/directory/fortress/core/impl/OrganizationalUnitP.html

It’s easy to wrap this API with REST but I’ve hesitated because no one’s asked for it.  However, the APIs referenced above are public and could be called from another (Java) program.  The hard part would be how the APIs are used. What I mean, again a tenant is a container.  Below that container are more containers, ou=People, ou=Roles, etc. 
Creating a new tenant would have to call the 

add(OrganizationalUnit orgUnit) method many times.  

So, the maybe not so easy part is creating a higher level method, that understands the concept of a fortress tenant and create all of the entries in the tree so the user doesn’t have to.  

addTenant( Tenant tenant )

This higher level method does not exist currently but it would be an interesting conversation of what one would look like.  If a clear idea emerges perhaps it can be implemented in the future.

>>>> - User role inheritance is pretty powerful, but why do we still need Group

As Yudhi pointed out Fortress is a framework for RBAC.  But, it does other things as well.  For example, traditional LDAP groups can be created with its APIs for usage in situations where RBAC enforcements doesn’t apply, like traditional Unix envs and legacy Web systems.

There’s another, more compelling use case: trusted logon.  This occurs inside environments where the end user of the app isn’t known, but the user's type or role is.  Think Oauth2, SAML or OpenStack[1] type logins. Here, we can create sessions using a group, which maps to the type of user logging into the system:

https://directory.apache.org/fortress/gen-docs/latest/apidocs/org/apache/directory/fortress/core/AccessMgr.html#createSession-org.apache.directory.fortress.core.model.Group-

The group that gets passed in, was assigned one or more roles.  When createSession is called with a group, its corresponding roles are activated into the session, and checkAccess can be used.

But, these are special use cases that don’t apply in many situations so that using the group object is often not needed.

Good questions.  Keep them coming.

—
Shawn

[1] FC-144 - Ability to assign groups to roles: https://issues.apache.org/jira/browse/FC-144


> On Sep 15, 2019, at 7:14 AM, Yudhi Karunia Surtan <yu...@apache.org> wrote:
> 
> Hi 何嘉权,
> 
> 1. Currently i don't think it is possible to add tenant, but that should be
> if you try to use ldap library directly. As long as you know the directory
> structure layout and ldap schema, that is possible.
> 2. Ya, currently i'm not using any Group for my current project
> implementation yet.(I'm using fortress from version 1.0.0-RC39)
> 3. It should be ok to have many permissions records, because later you just
> need to check using
> https://directory.apache.org/fortress/gen-docs/latest/apidocs/org/apache/directory/fortress/core/AccessMgr.html
> at
> checkAccess method.
> 
> In my opinion, fortress is giving you the framework of how rbac works. In
> the end, you are the one that need to define and fit it with your use case.
> Currently, I worked at blibli (http://www.blibli.com), one of the biggest
> e-commerce company in Indonesia.
> I'm using fortress and Apereo CAS to as the authentication and
> authorization of the most back-office management applications for all the
> microservices and successfully centralize the access management for all
> employees.
> Hopefully with my testimonial you can try to use it too, it just need
> little creativity to try to fit it with your use case since fortress is the
> implementation of Role-Based Access Control ANSI INCITS 359-2004.
> 
> Thanks
> 
> Regards,
> 
> 
> Yudhi Karunia Surtan
> --------------------------------------
> https://github.com/yudhik
> 
> 
> On Sun, Sep 15, 2019 at 1:02 PM 何嘉权 <ji...@9amai> wrote:
> 
>> Hi Yudhi,
>> 
>> Thanks for replying and sorry for my ambiguity.
>> 
>> We’re not implementing a second fortress. We’re learning to use it
>> correctly to avoid going to a wrong direction.
>> 
>> 1. We are wondering if Fortress provides any REST api to add new tenants.
>> Or should we implement one?
>> 2. Do you mean you’re not using groups?
>> 3. Surprised to know about this!
>> 
>> On Sun, Sep 15, 2019 at 1:39 PM Yudhi Karunia Surtan <yu...@apache.org>
>> wrote:
>> 
>>> Hi jiaquan,
>>> 
>>> 
>>> 1. What is ootb mean?
>>> 2. Currently I'm not using it.
>>> 3. Yes, since it is a whitelist of permission. Currently, I think I have
>>> more than 2000 perms at my current implementation at my company.
>>> 
>>> Anyway, what do you mean by best practice here? Is it about correctness
>>> how you implement it? Or how to exactly using fortress?
>>> 
>>> Sorry for my bad English.
>>> 
>>> 
>>> Regards,
>>> 
>>> 
>>> Yudhi Karunia Surtan
>>> 
>>> 
>>> 
>>> 
>>> On Sun, Sep 15, 2019, 10:18 何嘉权 <ji...@9am.ai> wrote:
>>> 
>>>> Hi mighty Fortress,
>>>> 
>>>> My team is evaluating how Fortress could fit into our product as an
>>>> access
>>>> control system.
>>>> 
>>>> We've gone through the major official documents, set up a demo with the
>>>> REST enmasse as well as the Web commander, and played with it a little
>>>> bit.
>>>> But we cannot find any best practice when it comes to our business
>>>> requirements.
>>>> 
>>>> We've multiple tenants with organizations of users, and organizations of
>>>> resources. According to our understanding of Fortress, we've ideas:
>>>> 
>>>> - Multiple tenants should be well supported as documented.
>>>> - User organization could be implemented with Fortress's role
>>>> organization.
>>>> - Resource organization could be implemented with Fortress's perm object
>>>> organization.
>>>> 
>>>> But then questions pop up and we fail to get any clue:
>>>> 
>>>> - By adding a new tenant, there's no OOTB RESTful API. [1]
>>>> - User role inheritance is pretty powerful, but why do we still need
>>>> Group
>>>> that doesn't have inheritance support? [2]
>>>> - If one tenant has 1,000 of resources, and each of them has READ/UPDATE
>>>> permission, is it expected to have 2,000 different permission objects in
>>>> Fortress?
>>>> 
>>>> Thanks for any advice.
>>>> 
>>>> [1]
>>>> 
>>>> https://github.com/apache/directory-fortress-core/blob/master/README-MULTITENANCY.md
>>>> [2] https://directory.apache.org/fortress/gen-docs/latest/apidocs/
>>>> 
>>> 


---------------------------------------------------------------------
To unsubscribe, e-mail: fortress-unsubscribe@directory.apache.org
For additional commands, e-mail: fortress-help@directory.apache.org

Re: Fortress best pratices?

[Yudhi Karunia Surtan <yu...@apache.org>]

Hi 何嘉权,

1. Currently i don't think it is possible to add tenant, but that should be
if you try to use ldap library directly. As long as you know the directory
structure layout and ldap schema, that is possible.
2. Ya, currently i'm not using any Group for my current project
implementation yet.(I'm using fortress from version 1.0.0-RC39)
3. It should be ok to have many permissions records, because later you just
need to check using
https://directory.apache.org/fortress/gen-docs/latest/apidocs/org/apache/directory/fortress/core/AccessMgr.html
at
checkAccess method.

In my opinion, fortress is giving you the framework of how rbac works. In
the end, you are the one that need to define and fit it with your use case.
Currently, I worked at blibli (http://www.blibli.com), one of the biggest
e-commerce company in Indonesia.
I'm using fortress and Apereo CAS to as the authentication and
authorization of the most back-office management applications for all the
microservices and successfully centralize the access management for all
employees.
Hopefully with my testimonial you can try to use it too, it just need
little creativity to try to fit it with your use case since fortress is the
implementation of Role-Based Access Control ANSI INCITS 359-2004.

Thanks

Regards,


Yudhi Karunia Surtan
--------------------------------------
https://github.com/yudhik


On Sun, Sep 15, 2019 at 1:02 PM 何嘉权 <ji...@9am.ai> wrote:

> Hi Yudhi,
>
> Thanks for replying and sorry for my ambiguity.
>
> We’re not implementing a second fortress. We’re learning to use it
> correctly to avoid going to a wrong direction.
>
> 1. We are wondering if Fortress provides any REST api to add new tenants.
> Or should we implement one?
> 2. Do you mean you’re not using groups?
> 3. Surprised to know about this!
>
> On Sun, Sep 15, 2019 at 1:39 PM Yudhi Karunia Surtan <yu...@apache.org>
> wrote:
>
>> Hi jiaquan,
>>
>>
>> 1. What is ootb mean?
>> 2. Currently I'm not using it.
>> 3. Yes, since it is a whitelist of permission. Currently, I think I have
>> more than 2000 perms at my current implementation at my company.
>>
>> Anyway, what do you mean by best practice here? Is it about correctness
>> how you implement it? Or how to exactly using fortress?
>>
>> Sorry for my bad English.
>>
>>
>> Regards,
>>
>>
>> Yudhi Karunia Surtan
>>
>>
>>
>>
>> On Sun, Sep 15, 2019, 10:18 何嘉权 <ji...@9am.ai> wrote:
>>
>>> Hi mighty Fortress,
>>>
>>> My team is evaluating how Fortress could fit into our product as an
>>> access
>>> control system.
>>>
>>> We've gone through the major official documents, set up a demo with the
>>> REST enmasse as well as the Web commander, and played with it a little
>>> bit.
>>> But we cannot find any best practice when it comes to our business
>>> requirements.
>>>
>>> We've multiple tenants with organizations of users, and organizations of
>>> resources. According to our understanding of Fortress, we've ideas:
>>>
>>> - Multiple tenants should be well supported as documented.
>>> - User organization could be implemented with Fortress's role
>>> organization.
>>> - Resource organization could be implemented with Fortress's perm object
>>> organization.
>>>
>>> But then questions pop up and we fail to get any clue:
>>>
>>> - By adding a new tenant, there's no OOTB RESTful API. [1]
>>> - User role inheritance is pretty powerful, but why do we still need
>>> Group
>>> that doesn't have inheritance support? [2]
>>> - If one tenant has 1,000 of resources, and each of them has READ/UPDATE
>>> permission, is it expected to have 2,000 different permission objects in
>>> Fortress?
>>>
>>> Thanks for any advice.
>>>
>>> [1]
>>>
>>> https://github.com/apache/directory-fortress-core/blob/master/README-MULTITENANCY.md
>>> [2] https://directory.apache.org/fortress/gen-docs/latest/apidocs/
>>>
>>

Re: Fortress best pratices?

[何嘉权 <ji...@9am.ai>]

Hi Yudhi,

Thanks for replying and sorry for my ambiguity.

We’re not implementing a second fortress. We’re learning to use it
correctly to avoid going to a wrong direction.

1. We are wondering if Fortress provides any REST api to add new tenants.
Or should we implement one?
2. Do you mean you’re not using groups?
3. Surprised to know about this!

On Sun, Sep 15, 2019 at 1:39 PM Yudhi Karunia Surtan <yu...@apache.org>
wrote:

> Hi jiaquan,
>
>
> 1. What is ootb mean?
> 2. Currently I'm not using it.
> 3. Yes, since it is a whitelist of permission. Currently, I think I have
> more than 2000 perms at my current implementation at my company.
>
> Anyway, what do you mean by best practice here? Is it about correctness
> how you implement it? Or how to exactly using fortress?
>
> Sorry for my bad English.
>
>
> Regards,
>
>
> Yudhi Karunia Surtan
>
>
>
>
> On Sun, Sep 15, 2019, 10:18 何嘉权 <ji...@9am.ai> wrote:
>
>> Hi mighty Fortress,
>>
>> My team is evaluating how Fortress could fit into our product as an access
>> control system.
>>
>> We've gone through the major official documents, set up a demo with the
>> REST enmasse as well as the Web commander, and played with it a little
>> bit.
>> But we cannot find any best practice when it comes to our business
>> requirements.
>>
>> We've multiple tenants with organizations of users, and organizations of
>> resources. According to our understanding of Fortress, we've ideas:
>>
>> - Multiple tenants should be well supported as documented.
>> - User organization could be implemented with Fortress's role
>> organization.
>> - Resource organization could be implemented with Fortress's perm object
>> organization.
>>
>> But then questions pop up and we fail to get any clue:
>>
>> - By adding a new tenant, there's no OOTB RESTful API. [1]
>> - User role inheritance is pretty powerful, but why do we still need Group
>> that doesn't have inheritance support? [2]
>> - If one tenant has 1,000 of resources, and each of them has READ/UPDATE
>> permission, is it expected to have 2,000 different permission objects in
>> Fortress?
>>
>> Thanks for any advice.
>>
>> [1]
>>
>> https://github.com/apache/directory-fortress-core/blob/master/README-MULTITENANCY.md
>> [2] https://directory.apache.org/fortress/gen-docs/latest/apidocs/
>>
>

Re: Fortress best pratices?

[Yudhi Karunia Surtan <yu...@apache.org>]

Hi jiaquan,


1. What is ootb mean?
2. Currently I'm not using it.
3. Yes, since it is a whitelist of permission. Currently, I think I have
more than 2000 perms at my current implementation at my company.

Anyway, what do you mean by best practice here? Is it about correctness how
you implement it? Or how to exactly using fortress?

Sorry for my bad English.


Regards,


Yudhi Karunia Surtan




On Sun, Sep 15, 2019, 10:18 何嘉权 <ji...@9am.ai> wrote:

> Hi mighty Fortress,
>
> My team is evaluating how Fortress could fit into our product as an access
> control system.
>
> We've gone through the major official documents, set up a demo with the
> REST enmasse as well as the Web commander, and played with it a little bit.
> But we cannot find any best practice when it comes to our business
> requirements.
>
> We've multiple tenants with organizations of users, and organizations of
> resources. According to our understanding of Fortress, we've ideas:
>
> - Multiple tenants should be well supported as documented.
> - User organization could be implemented with Fortress's role organization.
> - Resource organization could be implemented with Fortress's perm object
> organization.
>
> But then questions pop up and we fail to get any clue:
>
> - By adding a new tenant, there's no OOTB RESTful API. [1]
> - User role inheritance is pretty powerful, but why do we still need Group
> that doesn't have inheritance support? [2]
> - If one tenant has 1,000 of resources, and each of them has READ/UPDATE
> permission, is it expected to have 2,000 different permission objects in
> Fortress?
>
> Thanks for any advice.
>
> [1]
>
> https://github.com/apache/directory-fortress-core/blob/master/README-MULTITENANCY.md
> [2] https://directory.apache.org/fortress/gen-docs/latest/apidocs/
>