Thank you Shawn for all the information! On Mon, Sep 16, 2019 at 12:22 AM Shawn McKinney <[email protected]> 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 <[email protected]> > 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 何嘉权 <jiaquan.he@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 < > [email protected]> > >> 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 何嘉权 <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > >
