saml

7 posts

cloudflare

Catching rogue AI behavior with identity-aware analytics (opens in new tab)

AI usage is difficult to govern without knowing both who made each request and what normal usage looks like for that person or agent. Cloudflare’s new Identity-aware AI Gateway and User Insights address this by attaching verified identities to requests and detecting behavior that significantly deviates from historical patterns. Together, they provide centralized visibility, per-user cost controls, and anomaly detection without requiring additional setup for traffic already routed through AI Gateway. ## AI Gateway as a Central Control Plane - AI Gateway routes requests from applications, developer tools, and agent harnesses—including Claude Code, Codex, and GitHub Copilot—through one platform. - It provides centralized observability, security, governance, and spend management across providers such as OpenAI, Anthropic, Google, and Workers AI. - This centralization makes it possible to analyze usage consistently across both human users and automated agents. ## Identity-Aware Requests with Cloudflare Access - The Cloudflare Access integration places a custom domain, such as `ai.example.com`, in front of the gateway. - Organizations can: - Authenticate users through SAML-compatible providers such as Okta or Microsoft Entra. - Apply access policies to specific users. - Avoid distributing Cloudflare API keys. - Each authenticated request includes the Access user ID as `cf.user_id`. - Administrators can filter logs, analytics, and spending by the actual requester rather than by a shared API key. - Per-user spend limits can assign each person a separate budget and either block requests or route them to cheaper models after the limit is reached. - Planned improvements will use identity-provider groups to control model access and spending—for example, granting frontier-model access to machine learning teams while limiting support teams. ## User Insights and Behavioral Baselines - User Insights is available to all AI Gateway customers at no extra cost. - It analyzes existing gateway traffic without requiring additional configuration. - The feature builds behavioral profiles for every account, including both people and agents. - It tracks cost inefficiencies such as poor cache-hit rates and oversized context windows, but focuses primarily on whether usage is normal for that particular account. - Human users and automated agents are evaluated according to their own patterns: - Agents may have regular, predictable sessions. - Humans typically have more irregular prompts, timing, and session lengths. ## Session-Based Anomaly Detection - User Insights evaluates sessions rather than individual requests, reducing noise from isolated events. - Each session is compared with the account’s rolling 95th-percentile session cost over the previous 30 days. - A session becomes a strong anomaly candidate when it exceeds twice that personal p95 baseline. - This relative comparison avoids misleading fixed thresholds: - A $500 session may be normal for a consistently heavy user. - A $50 session may be highly unusual for an agent that normally spends $5. - Baselines adjust over time as an account’s usage changes. ## Combining Personal and Organization-Wide Thresholds - User Insights also applies an organization-wide p99 cost ceiling. - In the example analysis: - Most sessions cost less than $10. - The organizational p95 is $20. - The p99 is $200, meaning only 1% of sessions reach that amount. - Alerts are triggered only when a session is both: - More than twice the account’s personal p95. - Above the organization’s p99 ceiling. - This prevents alerts for: - Small-dollar spikes that are statistically unusual but not worth investigating. - Expensive sessions that are routine for a particular user. - A dollar floor also prevents tiny accounts from triggering alerts because of insignificant percentage increases. ## Filtering for Rogue Behavior - The resulting interface presents a feed of accounts that have broken their established usage patterns. - This focuses administrators on potentially meaningful incidents instead of showing every unusual request. - The approach is designed to detect trusted users or agents that suddenly perform more of an already-authorized activity—behavior that traditional controls may not block because no new tool or forbidden action is involved. Cloudflare’s recommendation is to route AI traffic through AI Gateway, authenticate it with Cloudflare Access, and use identity-based budgets alongside behavioral baselines. This combination helps organizations connect spending and activity to specific people or agents while concentrating investigations on statistically significant, high-impact deviations.

gitlab

Keep your GitLab seats in check with restricted access (opens in new tab)

GitLab’s restricted access feature helps organizations prevent unexpected seat overages by blocking new billable users once all purchased seats are occupied. Recent improvements make it work more reliably with SAML, SCIM, LDAP, OIDC, and SSO provisioning, while providing clearer warnings and audit information. The feature is forward-looking: it prevents future growth but does not automatically resolve existing overages. ## How restricted access controls seats - Available on GitLab.com and Self-Managed. - When all licensed seats are used, new billable users cannot be added. - Users who only need authentication can receive the non-billable Minimal Access role. - Existing billable members are not downgraded or removed when restricted access is enabled. - Organizations must resolve current overages by removing users or purchasing more seats. ## Identity provider integration - Users provisioned through SAML, SCIM, or LDAP are assigned Minimal Access when no paid seats are available. - Automated synchronization can continue without immediately creating billable overages. - OIDC-only users can be assigned Minimal Access at the top-level group and authenticate without consuming seats. ## Dormant user reactivation - GitLab can deactivate inactive users to free seats. - Previously, SSO or OIDC sign-ins could silently reactivate dormant users as billable members. - With restricted access enabled and no seats available, reactivated users enter a pending approval state. - Their existing group and project memberships are preserved until an administrator approves them. ## Improved operational visibility - Configuration warnings now appear for LDAP, SAML group links, and SCIM. - GitLab distinguishes between approaching and reaching the seat limit. - Group owners and instance administrators can receive email notifications when users fall back to Minimal Access. - Audit logs show Minimal Access fallback events. ## Self-Managed settings cache Self-Managed installations cache application settings for 60 seconds by default. Changes between restricted access and user cap may therefore take up to a minute to appear consistently. Administrators can adjust the cache interval if necessary. ## Restricted access versus user cap - **Restricted access:** Controls additions based on available licensed seats. - **User cap:** Sends new users into an administrator approval workflow regardless of seat availability. - The two features cannot be enabled simultaneously; enabling restricted access automatically disables user cap. ## Enabling the feature - **GitLab.com:** Settings > General > Permissions and group features > Seat control > Restricted access. - **Self-Managed:** Admin > Settings > General > New user account restrictions > Seat control > Restricted access. - GitLab.com does not support restricted access when the top-level group is shared with an external group. Restricted access is recommended for organizations seeking predictable licensing costs while retaining automated identity provisioning and controlled user reactivation.

gitlab

GitLab Patch Release: 19.0.2, 18.11.5, 18.10.8 | GitLab Docs (opens in new tab)

GitLab released patch versions 19.0.2, 18.11.5, and 18.10.8 on June 10, 2026, addressing important security and bug fixes. Self-managed installations should upgrade immediately; GitLab.com is already patched, while GitLab Dedicated customers need no action. The fixes affect both CE and EE and cover account takeover, cross-site scripting, denial of service, authorization bypasses, and server-side request forgery. ## Release Scope and Upgrade Guidance - Affected self-managed installations should upgrade to the latest patch release for their supported GitLab version. - The releases apply to GitLab Community Edition and Enterprise Edition. - GitLab publishes: - Scheduled patch releases twice monthly, on the second and fourth Wednesdays. - Ad-hoc critical patches for high-severity vulnerabilities. - Security issues are generally made public on GitLab’s issue tracker 30 days after the release containing their fix. - GitLab.com has already deployed the patches, and GitLab Dedicated customers do not need to take action. ## High-Severity Enterprise Edition Vulnerabilities - **CVE-2026-6552 — Group SAML Identity API** - CVSS 8.7. - An authenticated group Owner could potentially take over another member’s GitLab account through improper authorization. - Affects GitLab EE versions before 18.10.8, 18.11.5, and 19.0.2. - **CVE-2026-10087 — Analytics Dashboard XSS** - CVSS 8.7. - An authenticated developer could execute arbitrary client-side code on behalf of another user due to inadequate input sanitization. - Affects EE versions before the patched releases. - **CVE-2026-8589 — HTML Injection in Group Settings** - CVSS 7.3. - Improper sanitization could allow unauthorized email addresses to be added to a targeted user’s account. - Requires significant privileges and user interaction. ## Denial-of-Service Vulnerabilities - **CVE-2026-7250 — Grape API JSON Parsing** - CVSS 7.5. - An unauthenticated attacker could cause denial of service through malformed API request input. - Affects CE and EE versions dating back to 12.10. - **CVE-2026-1500 — Group Placeholder Reassignments API** - CVSS 6.5. - An authenticated user could trigger uncontrolled resource consumption with a specially crafted file upload. - Affects CE and EE versions beginning with 17.10. - **CVE-2026-10733 — CI/CD Catalog HTML Injection** - CVSS 4.3. - Improper sanitization could allow an authenticated user to disrupt the CI/CD Catalog page. ## Authorization and Data-Access Issues - **CVE-2026-6269 — Merge Requests API** - CVSS 5.4. - Developers could modify hidden merge requests because of incorrect authorization enforcement. - **CVE-2026-6277 — Security Inventory** - CVSS 4.3. - Security Managers could modify project security configuration even when the related feature was disabled. - **CVE-2026-6976 — Merge Request Diff** - CVSS 3.7. - Developers could hide changes from merge request diffs through improperly handled file names. ## Server-Side Request Forgery - **CVE-2026-9204 — Gitaly Repository Import** - CVSS 5.3. - An authenticated user could potentially read arbitrary files from the Gitaly server or access internal network resources during repository import. - The issue resulted from insufficient validation of secondary URLs. ## Recommendation Administrators of self-managed GitLab instances should upgrade to 19.0.2, 18.11.5, or 18.10.8 as soon as possible, regardless of whether they use Omnibus, source installations, or Helm charts.

aws

Improve your application resilience with Amazon Cognito multi-Region replication | Amazon Web Services (opens in new tab)

Amazon Cognito multi-Region replication improves authentication resilience by maintaining synchronized user data, credentials, configurations, and machine secrets in a secondary AWS Region. During a regional outage, applications can redirect traffic while users continue using existing credentials and sessions, though registration and profile updates are unavailable during failover. The feature also adds customer managed AWS KMS keys for consistent, customer-controlled encryption across Regions. ## Challenges with Regional Failover - Custom replication solutions previously required significant engineering effort. - Manual user-data transfers introduced security and consistency risks. - Users could be forced to reset passwords or authenticate again after a regional switch. - Machine-to-machine systems required new app clients, application reconfiguration, and updated OAuth resource trust settings. ## How Multi-Region Replication Works - Replication is one-way, from a primary Region to a secondary Region. - The replica includes: - User profiles and credentials - User pool configuration - Machine-to-machine secrets - The secondary pool is read-only and remains available for authentication. - Existing sessions continue uninterrupted. - Users can authenticate with existing credentials, and either Region recognizes access tokens issued by the other. - Supported authentication methods include: - Social identity providers - SAML and OIDC federation - API authorization flows - Machine-to-machine authentication - New registrations and profile changes are unavailable while operating from the replica. ## Customer Managed KMS Keys - A multi-Region customer managed key is required before replication can be configured. - The key must be replicated into both the primary and secondary Regions. - Its policy must grant Amazon Cognito permission to use the key. - Customer managed keys provide consistent encryption across Regions and greater control over encryption policies. ## Configuration Process - The console guides administrators through three main steps: - Select and configure the customer managed KMS key. - Configure multi-Region OIDC issuer endpoints. - Select and create the replica Region. - Client applications must be updated with the new OIDC endpoints. - Server-side applications require redeployment, while mobile applications require updated store submissions. - After the replica is prepared, an administrator must manually activate it. ## Additional Regional Resources - Lambda functions used for custom authentication, SMS, or email must be deployed and configured in the secondary Region. - Logging and AWS WAF settings must also be recreated there. - Teams should verify that all supporting authentication infrastructure is available before failover. ## Health Checks and Failover - Both regional endpoints remain active and ready to serve traffic. - Applications should define health checks based on error rates, latency, or service alerts. - DNS can redirect traffic to the secondary Region when failover criteria are met. - Teams should test failover during low-traffic periods, potentially routing only a small percentage of traffic initially. - Managed login and federation with custom domains can use Amazon Route 53 health checks for built-in traffic routing. ## Pricing and Availability - Replication is available as an add-on for Cognito Essentials and Plus tiers. - User authentication costs: - $0.0045 per monthly active user per replica Region for Essentials - $0.006 per monthly active user per replica Region for Plus - M2M replication adds 30% to standard successful-token pricing. - The feature is available across selected Regions in North America, Europe, Asia Pacific, Canada, Africa, and South America. Organizations needing resilient authentication should pair Cognito replication with multi-Region KMS keys, replicated supporting services, tested health checks, and an automated or well-practiced DNS failover process.

aws

AWS IAM Identity Center now supports multi-Region replication for AWS account access and application use | Amazon Web Services (opens in new tab)

AWS IAM Identity Center now supports multi-Region replication for organizations using an external identity provider such as Microsoft Entra ID or Okta. Workforce identities, permission sets, and related metadata can be replicated from a primary Region, allowing users to access AWS accounts and managed applications if the primary service is disrupted. The feature also supports regional application deployment for improved performance and data residency compliance, with centralized configuration remaining in the primary Region. ## Multi-Region Replication and Resilience - Replication provides an active AWS access portal endpoint in each additional Region. - Users can continue accessing AWS accounts with already-provisioned permissions during a primary-Region disruption. - AWS managed applications can access replicated identities locally, improving reliability and proximity to users or datasets. - IAM Identity Center configuration remains centrally managed from the primary Region. ## Prerequisites and Setup - The feature requires: - An organization instance of IAM Identity Center. - An external IdP, such as Okta or Microsoft Entra ID. - Primary and additional Regions that are enabled by default. - Before replication, the customer-managed AWS KMS key must be replicated to the target Region. - AWS recommends multi-Region KMS keys because they maintain consistent key material across Regions while preserving independent regional infrastructure. - In the IAM Identity Center console, administrators select **Settings → Management → Add Region** and choose the target Region. - Initial replication time depends on the size of the Identity Center instance. ## User Authentication and Access - Administrators must add the additional Region’s SAML Assertion Consumer Service (ACS) URL to the external IdP configuration. - A bookmark application can be created in the IdP to provide users with direct access to the new Region’s AWS access portal. - Users can access accounts and applications through existing methods, including: - The AWS access portal - Application links - The AWS CLI ## Regional Application Deployment - AWS managed applications can be deployed in additional Regions using existing deployment workflows. - Organizations can place applications near regional datasets to satisfy performance or data residency requirements. - Administrators should verify that each required managed application supports both the selected Region and multi-Region deployment. ## Operational Considerations - Additional Regions provide a limited-management console experience. - Most operations outside the primary Region are read-only, except application management and user session revocation. - Workforce activity is recorded in AWS CloudTrail in the Region where it occurs. - Break-glass access is recommended for privileged users if the external IdP becomes unavailable. - Account instances, Microsoft Active Directory identity sources, and the built-in IAM Identity Center directory are not supported at launch. ## Availability and Cost - The feature is available at no additional IAM Identity Center cost in 17 enabled-by-default commercial AWS Regions. - Standard AWS KMS charges apply for customer-managed key storage and use. Organizations using supported external IdPs should replicate IAM Identity Center into strategically selected Regions, configure the required KMS replicas and ACS URLs, and test regional access and emergency procedures before relying on the setup for disaster recovery.

figma

Inside Figma: securing internal web apps | Figma Blog (opens in new tab)

Figma built a reusable system for securely exposing internal web applications while preserving a smooth employee experience. The design combines AWS Application Load Balancers, Cognito, Okta, SAML, Lambda, and Terraform to enforce zero-trust authentication and centralized authorization. Its main conclusion is that carefully integrated, managed cloud components can provide strong security without creating excessive operational work for a small security team. ## Security Requirements for Internal Applications Figma’s internal web tools support critical workflows such as software deployment and customer support, making them attractive targets for attackers. The system was designed around five requirements: - **Smooth user experience:** Authentication should be fast, reliable, and convenient. - **Zero-trust access:** Network location alone should not establish trust. - **Modern authentication:** Applications should be able to use protections such as WebAuthn. - **Centralized authorization:** IT and security teams should centrally assign, monitor, and revoke permissions. - **Low operational overhead:** The system should minimize ongoing SRE and security-team toil. ## Technologies Used The architecture relies primarily on managed services and infrastructure-as-code: - **SAML:** Exchanges identity, group membership, and role assertions between services. - **AWS Application Load Balancer:** Acts as a managed reverse proxy and routes authenticated HTTP/HTTPS traffic. - **AWS Cognito:** Provides user-pool functionality and integrates with federated SAML identity providers. - **AWS Lambda:** Runs code in response to configured events without managing servers. - **Terraform:** Defines and automates AWS and Okta configuration through reusable modules. ## Application Load Balancers, Cognito, and Okta Figma uses AWS for infrastructure and Okta for employee authentication and authorization. - ALBs can authenticate traffic using OIDC, but Okta charges extra for OIDC support. - Figma instead uses the ALB’s SAML authentication capability together with an AWS Cognito user pool. - Terraform modules automate the creation and configuration of the required ALB and Cognito resources. - These modules allow infrastructure engineers to quickly deploy internal applications protected by the company’s Okta environment. - The Cognito user pool disables self-registration. - Each pool connects to a Cognito identity provider backed by a SAML Okta application created for the specific internal application. - Attribute mappings are configured so user information such as `email` and `profile` is passed through the authentication flow.

figma

Keeping your data in Figma safe and secure: SOC 2 Type 2, SSO, and more | Figma Blog (opens in new tab)

Figma presents security as a core part of its infrastructure and product development, emphasizing protection of customer data and design intellectual property. Its efforts include SOC 2 certification, privacy compliance for European customers, secure plugin architecture, and enterprise SAML single sign-on. An update later confirmed that Figma completed SOC 2 Type 2 certification and obtained a SOC 3 report. ## SOC 2 Certification - Figma initially achieved SOC 2 Type 1 certification after auditing its infrastructure, software, HR processes, and customer-data policies. - Type 1 evaluates controls at a specific point in time. - Type 2 provides stronger assurance by examining whether those controls operate effectively over an extended period. - By January 2020, Figma had completed SOC 2 Type 2 certification and secured a publicly downloadable SOC 3 report. ## European Data Protection - Figma highlights its readiness for growing European usage. - It complies with relevant data-protection requirements and was certified under: - The EU–U.S. Privacy Shield Framework - The Swiss–U.S. Privacy Shield Framework ## Security-First Product Development - Security is considered during the design of new features, not added afterward. - Figma’s plugin system deliberately limits access: - A plugin can access only one design file at a time. - Plugins cannot access a user’s entire account. - Plugins are isolated from one another’s data. - Plugins cannot modify Figma’s user interface, reducing phishing and user-misdirection risks. - These restrictions sometimes reduced available capabilities, but Figma prioritized security, stability, and performance. ## SAML Single Sign-On - SAML integrations help organizations deploy Figma securely and manage user access centrally. - Figma supported Okta and Microsoft Azure Active Directory, and added OneLogin. - Enterprise administrators can simplify authentication while maintaining organizational access controls. Figma’s overall approach is to combine independent compliance audits, privacy frameworks, careful product architecture, and centralized enterprise authentication. Organizations evaluating Figma should review its security and privacy documentation and consider enterprise SSO controls for managing access.