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]
