Hi Steve, thanks for weighing in, happy holidays to you and our friends at Penn State.
There are already some in the python community, i.e. openstack, that are accessing fortress apis via fortress-rest, so no need to spend time there. But there are two other options for a python fortress that are interesting. One, is connecting to the rbac accelerator, which is an openldap overlay Symas developed several years ago. https://symas.com/tag/open-ldap-rbac-accelerator/ A fortress accelerator client in python has already been written, by the University of Hawaii around the same time the server overlay was developed, but that code has never been released. So this could be re-implemented. The advantage is the accelerator client code is simpler, having only to drive the extended controls, much in the way of the openldap fortress java client that Emmanuel Lecharney implemented a few years back. Another advantage is performance, which was the whole point of the accelerator plug-in, bringing > 2X performance improvements on server roundtrips, as documented some time ago. A disadvantage is being tied to openldap, and not interoperating with other server impls, like apacheds. The second python option is to reimplement what the fortress java core does, only for the accessmgr interface, which is about 6 operations: 1. createSession 2. checkAccess 3. sessionPermissions 4. sessionRoles 5. addActiveRole 6. dropActiveRole to start, *only* support RBAC0, which vastly simplifies req’s. I believe this would be relatively easy to do. A prototype could be available within a few weeks. If this concept takes hold, we could improve gradually, adding support for RBAC1, 2, 3. As for the ‘why’. I believe some of the more interesting security work being done today is on the python platform. It’s simple and relatively stable. In contrast, Java enterprise application frameworks are more volatile than ever. The Cloud has introduced many new, complexities that have effectively obfuscated our view of security requirements in those runtime envs. For example, we now have springboot (where’s the container), system containers (of many flavors and sizes), microservices, orchestration apis and controllers, etc. These new approaches have hidden from our view *where* the security controls must be placed, *how* they are to be done, and *who* is responsible for them. Yes, there have been recent improvements in the specifications with Java EE 8, i.e. JSR 375, but this improvement is coming very late in the game, after many previous missteps (i.e. JAAS, JSR-115, ...) and it’s anyone guess if it will actually catch on. I hope so, but we shall see. This complexity and volatility has splintered and confused security concerns to such an extent that it has created paralysis in security engineers on the Java platform. There is no agreed upon methodology or protocol for authZ. As a result, only coarse-grained and primitive controls are being used. Or the concern is being totally left to the application, meaning not being done at all, or very poorly. So the Fortress Java core withers on the vine... Meanwhile there’s a well understood need within the python community for standards-based authorization, i.e. RBAC, and a python fortress that is fully LDAPv3 compliant might fill that void. Shawn > On Dec 18, 2017, at 11:12 AM, Steve Moyer <[email protected]> wrote: > > That seems like a ton of work! > > There is a Python library that reads a WADL and creates a typed REST client. > Wouldn't it be easier to use the existing Fortress REST service as an > intermediate API? I know this requires that users run an LDAP server > configured for use with Fortress and an Application Server to provide the > REST service but it seems like a good compromise. > > I'm not sure what the impetus is for a PyFortress so I don't want to sound > too negative. In the mean-time, have a very merry Christmas! > > Steve > > "That ginormous thing like, all over there (pointing), is the Millenium > Science Complex" - Backwards Walker to prospective PSU students
