Recently we introduced you to the exciting new release and integration with IDF Connect (you can read Part 1 of the blog here). In part 2 of this series, we asked our two experts – Richard Sand from IDF Connect and Gerry Gebel from Axiomatics, to take us through the details of this integration and the benefits for organizations of any size.

  • Access management requirements have evolved over the years
  • Enterprises have had to choose between security and functionality
  • Web resources are another type of resource that Axiomatics can protect, regardless of where they are deployed

 

Gerry: How does authentication work with SSO/Rest and Axiomatics? Where does XACML fit in?

Richard: Authentication can occur directly against an LDAP, DB, or an authentication web service – basically against any back-end that is supported by SSO/Rest. XACML is used by SSO/Rest specifically for policy evaluation: both for determining if a resource (i.e. a URL) is protected by policy and for how, if necessary, the end user should be challenged. XACML policies are then evaluated to determine if the authenticated user is actually authorized to the requested resource.

Additional obligations and advice are used to provide instructions about session management and  other HTTP operations, such as setting request headers or adding cookies. SSO/Rest has defined approximately twenty urns for obligations and advice with specific meaning for web access management.

 

Gerry: How is enforcement done (e.g. “last mile” integration) into the web applications?

Richard: “Last mile” integration is performed by SSO/Rest plugins. SSO/Rest is composed of a gateway and plugins. The plugins are the policy enforcement points (PEPs), and hand off the requests to the applications (when allowed by policy). The plugins will assert additional request headers that convey user and session information to the applications.

What makes our plugins unique is that they are lightweight, single library plugins, and can be included directly into the application as dependencies, incorporated into CI/CD pipelines, and deployed with the apps onto platform-as-a-service providers

The gateway portion of SSO/Rest, essentially a hardened Cloud Access API gateway, sits protected in the DMZ. It talks to the plugins via REST-compliant web services, handles the resource-intensive crypto, and securely mediates communication between the plugins and Policy Decision Points.

 

Gerry: Don’t SAML, OAuth and/or OIDC provide everything we need for SSO?

Richard: SAML, OAuth, OIDC, Shibboleth, WS-FED –  these technologies all provide variations on the “claims-based” or “ticket” method for handling authentication, and optionally for also conveying roles, entitlements, and profile data. The important point to recognize is that with all of these methods the burden always falls on the recipient (i.e. the application), to consume these tickets properly and react accordingly. This type of architecture is perfectly adequate for many applications, especially those that are consumer-oriented or don’t otherwise have strict security and compliance requirements. Enterprises, however, will frequently require more fine-grained control over access policies­ – including their creation, enforcement, and auditing – than such systems can easily provide.

We believe that enforcement is best done by forming a perimeter in front of the applications, so that policies can be declared centrally and additional security checks can be integrated quickly and easily, but while still allowing for modern development and deployment practices. While our plugins are able to receive these tickets, perform the validation, and convert them into an SSO session, our perimeter-based approach goes well beyond the limitations of the ticket method by performing direct access control enforcement. With perimeter enforcement, administrators can assign fine-grained policies to individual users, store them securely in an on-premise or cloud-based Policy Decision Point (PDP) and enforce them at the Policy Enforcement Point (PEP) (i.e. the SSO/Rest plugins). Every request for access is vetted. The tighter perimeter that this method achieves is especially crucial for applications with higher security requirements; e.g. online banking, ERP apps, PCI-related apps, etc.

 

Gerry: What does IDF Connect mean by “SSO/Rest provides fluidity to your existing access management solution”?

Richard: By “fluidity” we mean that SSO/Rest doesn’t just extends the power and capabilities of your existing access management solution; it also provides you with a migration path for moving from one platform to another, including platforms in the Cloud. IDFC focuses heavily on the transformation process that organizations must undergo to move apps and assets to the Cloud, and our tools ensure that organizations can undertake these transformations in an orderly, stepwise fashion – as opposed to a single “big bang” cutover approach. Essentially, the journey is just as important as the destination!

 

Gerry: We hear a lot about HEAVY agents and the slow speed and dismal performance of legacy Web Access Management solutions when attempting to use them in the cloud. Tell us how this new technology helps alleviate these well-known pain points.

Richard: Well, all pre-Cloud WAM products depend on heavyweight agents or proxies. These products provide perimeter authentication and access control enforcement, logging people into applications and intercommunicating using vendor-specific, proprietary protocols. And, for the most part, they worked just fine for the world for which they were designed. But if you try to use them in the Cloud, their heaviness is compounded by increased network latency, degrading performance. And even worse, their reliance on non-standard protocols requires enterprises to open network tunnels or punch new, unsafe holes through multiple layers of firewalls. They simply cannot be implemented in Cloud-based applications without significant loss of WAM functionality, complication of perimeter safeguards, and interruption of smooth user experience.

SSO/Rest solves this problem by providing a complete WAM solution as a set of REST-based Web services called the SSO/Rest Gateway. We replace the clunky agents/proxies with our ultra-lightweight plugins which then communicate with the REST services via HTTPS. The plugins have a tiny footprint; they don’t rely on any external code libraries, and don’t perform any processor-consuming cryptographic operations or token validations – all the heavy lifting is done at the hardened Gateway, which, sitting protected in the enterprise DMZ, securely mediating communication between the plugins and Policy Decision Points. And because the plugins communicate solely via HTTPS no new firewall ports need to be opened. Together, these innovations mean that enterprises can deploy the plugins on applications both inside and outside the enterprise perimeter, thereby creating a virtual perimeter to encompass any cloud-deployed applications the organization wishes to secure.

 



Leave a Reply

Your email address will not be published. Required fields are marked *