> On Aug 18, 2020, at 6:34 PM, John Tumminaro <[email protected]> wrote: > > 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: > • The Client has already chosen SaaS Okta as the IAM solution, so from > an Authentication perspective, Okta is the System Of Record. > • 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. > • 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.
Can you explain how the integration with AD will work? Will there be a new domain/replica created just for fortress data access? What will the system architecture look like? > • 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. OK > • The client has very strict Technology Selection Principles as follows: > • Cloud-first > • AWS-first > • PaaS-first > • The PaaS-first principle is perhaps most important here because it > biases towards supporting-services which are hosted and managed by a services > provider. > • 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. Makes sense. > • The Client is aligned with the ANSI RBAC model and is also aligned > with Apache Fortress as the underlying Implementation and API. All important for success this is. > • 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? > Looks good so far… — Shawn --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
