Fixing Enterprise IAM – Automation – Self-Service – Security – Rapid Adoption

Fixing Enterprise IAM: Automation, Self-Service, Security, Rapid Adaption

Day/Session:Wed 2G

Convener:Jon Lehtinen

Notes-taker(s): Jon Lehtinen

Tags for the session - technology discussed/ideas considered:

Self-service, automation, containerization, devops, identity governance, single sign-on, OIDC, SAML, Virtual Directory Services, MFA, identity governance

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

As identity/security professionals AND individuals, it is in our interest to make sure enterprise environments are running modern, hardened identity stacks to not only prevent the breaches that damage the business, but also harm customers through the loss of their data. The issue is that the enterprise is often loathe to spend the money necessary to modernize their IAM posture, or staff it to the level equal to the challenge. As such, we want to explore and discuss the strategies we can use to maximize the impact of our efforts in modernizing the enterprise IAM stack to protect the business and customers, while working within the monetary and staffing constraints imposed upon most IAM/security teams. 

Self-Service & Automation as a force multiplier/cost savings measure

Infrastructure and Operations

Containerization, devops, and cloud-first design

Rapid iteration/upgrade of IAM systems through containerization

-Opportunity for CI/CD pipelines to refresh container images for automated redeployment when task/container fails

-Frequent environment rehydration sidesteps costs/staffing/time involved with maintaining long-lived servers

What services are candidates for cloud deployments?

SSO (particularly federation services)

-Participants felt this is fine for cloud/container deployments

-Allows good user experience for a global workforce

MFA

-Often offered as a cloud service presently. Offering to the business as a function of the SSO service reduces friction and eases integration/consumption of MFA by keeping the application integration aligned to SSO using protocols like OIDC & SAML.

-Step-up auth available to app teams via an end point or API

-Special integrations may still be offered (e.g. offline & ssh)

Privileged Access Management

-NOT recommended for cloud

-Hypervisor attacks could lead to theft of vault

Directory Services

-Attribute stores close to IDP for cloud deployments

-Credential validation could be isolated to its own VPC with explicit access only granted to the SSO system. All other applications could perform LDAP attribute lookups using an attribute store on a separate directory. Identity Governance

-Was not discussed, though this is offered as a cloud-based/SaaS offering from some vendors.

Application integration to IAM services

SSO self-service

-Offer API for Oauth/OIDC client registration (such as dynamic client registration) for technically proficient internal customers/app teams

-Offer friendly GUI to that API for the non-technical internal customers who must enroll an app into SSO

-Documentation, customer engagement, open office hours, and templated solutions reduce the friction for delegating the work of app integration after issuing the "hook" to the IDP

-OIDC further reduces this friction as certified solutions for various languages/middleware facilitate the migration to OIDC from other access management solutions.

Push for OIDC over SAML

-OIDC is much simpler for self-service

-Dynamic Client Registration can be called after some sort of governance flow (like service now) that includes security, technical, and business approvers.

-SAML is HARD

-SaaS apps as each SaaS app has its own schema and requirements

-In previous org, the convener ultimately built a comprehensive self-service portal to accommodate several use cases based on customer feedback using a product management strategy, but that took time, and we functionally built a very friendly skin of the IDP administrative console by the time we were done. And even then it could not handle every SaaS use case.

-Internal apps can be forced to use a prescribed attribute package

-High hopes that FastFed will ameliorate this, but even after ratification FastFed will depend upon adoption by SaaS providers to improve this situation

IGA self-service

-This was hard. SCIM was supposed to help, but not as many SCIM ready apps as we thought there would be by now.

-Produce a frame work for self-enrollment for applications into authorization/entitlement enrollment/workflow review using Oauth tokens to delegate the auth prior to writing the connection in IGA

-Requires IGA-specific hooks to implement on a per-product basis, but would improve what is presently a tedious and time-consuming process.

Directory services

-Offer virtual directory views to applications which require LDAP through a self-service portal

-Requires individual integration with virtual directory product, no standards-based protocol to write the view

-Do you even want to offer LDAPS in such a fashion moving forward for your business? Remember your strategy. Increasing friction on old protocols and making newer protocols easier to consume can help drive the business in the direction needed to retire technical debt.

Fine-grained authorization service for applications?

-When offering self-service for SSO via OpenID/SAML, coarse grained use cases are addressed

-Very rough authZ decisions are made/enforced at the IDP at the time of authentication, e.g. terminated users cannot proceed.

-Is it desirable to offer a centralized, per-app, fine-grained authZ policy service?

-Discussion indicated that NO, enforcing coarse-grained AuthZ at the IDP was sufficient, and that fine-grained authZ could then be delegated and managed by the application owners as a function of their SSO integration.

-UMA2 endpoints could marry central policy management with self-service and per-app edge enforcement

-An app owner defines the policy (including per-path authZ policies using the UMA2 endpoints), and registers the UMA2 client using self-service. Now there is a record of fine-grained policies centrally, managed by the application owner (not IT security), and enforced at the application during logon through review of the UMA2 policy.