Yudhi, nice to meet you and thanks for the reply.
The current thinking for my Client is to use Apache Fortress with AWS
Directory Service as the underlying LDAP server.
Below is the reasoning for this...please feel free to challenge any of it
as we are just conjuring this up and we are very open to alternative
approaches or identifying any flaws in our thinking:
1. The Client has already chosen SaaS Okta as the IAM solution, so from
an Authentication perspective, Okta is the System Of Record.
2. There is an existing Corporate AD Server (which will ultimately be
integrated with Okta) but it has been declared as off limits for any other
use...with no exceptions.
3. The intent of using Apache Fortress is strictly for the standalone
Application Level RBAC capability, in other words, the Apache Fortress APIs
will be used in "isTrusted" mode without Passwords or Authentication.
4. RBAC Auditing is intended to be done at the Application Level in a
custom/specific manner, so it is acceptable if Apache Fortress does not
audit.
5. The client has very strict Technology Selection Principles as follows:
1. Cloud-first
2. AWS-first
3. PaaS-first
6. The PaaS-first principle is perhaps most important here because it
biases towards supporting-services which are hosted and managed by a
services provider.
7. If OpenLDAP (or any other IaaS supporting-service) were to be
suggested, it would go against the PaaS-first principle and would require
overwhelming reasoning as to why.
8. The Client is aligned with the ANSI RBAC model and is also aligned
with Apache Fortress as the underlying Implementation and API.
9. Provisioning/Deprovisioning of Users (and their associated RBAC
configuration) will be done at the Application Level via custom
automated/manual Administrative Interfaces.
So, would you say that the above reasoning holds water...or did we miss
something?
Thanks,
John
On Tue, Aug 18, 2020 at 6:42 AM Yudhi Karunia Surtan <
[email protected]> wrote:
> Hi John,
>
> I'm not sure why you would like to use AD rather than openldap.
> If the reason is about the existing credentials only i used SASL from
> openldap to delegate the authentication to AD.
> So before we use fortress in our company, previously AD already existed at
> the beginning to maintain other computer email and their windows
> credentials.
> Since most open sources don't work well with AD, I asked to use openldap
> for all the internal applications that we build rather than use AD.
> The only thing that I did was create a scheduler to sync AD user entries to
> my fortress people tree.
> Hope these answers might help you.
>
>
> On Sat, Aug 15, 2020, 10:03 Shawn McKinney <[email protected]> wrote:
>
> >
> > > On Aug 14, 2020, at 2:06 PM, John Tumminaro <[email protected]>
> > wrote:
> > >
> > > Hello All, I'm new to the mailing list.
> > >
> >
> > Hello John, welcome!
> >
> > > I think I understand that Apache Fortress works with any underlying
> LDAP
> > V3
> > > server.
> > > I believe the Microsoft Active Directory Server supports LDAP V3.
> > >
> > > I think I remember hearing that Apache Fortress will indeed work
> > > with Microsoft Active Directory Server for all RBAC
> > > functionality...except...the Apache Fortress auditing capability will
> not
> > > work.
> > >
> > > Do I have my facts right?
> > >
> >
> > Yes, it’s possible but there are a few problems.
> >
> > 1. As you pointed out, no audit trail.
> >
> > 2. Password policies won’t be checked.
> >
> > 3. Requires adding custom schema elements to the server which is
> sometimes
> > hard to get approved.
> >
> > 4. Requires read/write access to the directory which is hard to get
> > approved.
> >
> > Despite these problems it’s something that we’d be willing to support.
> It
> > might require some minor changes to the core, to workaround AD anomalies.
> >
> > The approach would be to run the junit tests against an AD instance and
> > fix the problems until the tests run without errors.
> >
> > Do you have access to an AD instance?
> >
> > > Thanks,
> > >
> > > John
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >
>
