single-sign-on

5 posts

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.

cloudflare

Mind the gap: new tools for continuous enforcement from boot to login (opens in new tab)

Cloudflare introduces two tools to enforce security continuously from device boot through application access: mandatory authentication and independent MFA. Mandatory authentication prevents unauthenticated devices from accessing the Internet, while Cloudflare MFA adds a second trust authority beyond the identity provider. Together, they reduce visibility gaps and limit the impact of compromised credentials. ## Closing the Authentication Gap - Cloudflare One Client provides policy enforcement and traffic inspection, but historically left devices exposed before a user authenticated or after a session expired. - In these “unknown device” states, users could potentially bypass controls using local machine connectivity. - Mandatory authentication, configured through MDM, makes the client enforce access from system boot: - Blocks Internet traffic using the system firewall. - Permits only the client’s authentication flow through a process-specific exception. - Prompts users to authenticate directly. - The feature will initially support Windows, with other platforms planned. ## Independent MFA at the Network Edge - SSO providers such as Okta, Entra ID, and Google are valuable security anchors but also high-value targets. - If an attacker hijacks an SSO session, they may gain access to every connected application. - Cloudflare MFA provides an independent, network-edge “step-up” factor, requiring attackers to overcome a second authority even if the primary IdP is compromised. - Supported methods include: - Biometrics such as Windows Hello, Touch ID, and Face ID. - WebAuthn, FIDO2, and PIV security keys. - TOTP authenticator applications. ## Granular Policy Enforcement - Administrators can require MFA globally, per application, or within specific access policies. - Organizations can match authentication strength to resource sensitivity—for example, weaker methods for chat and security keys for source-code repositories. - Strong MFA can be imposed on contractors using personal identities or social logins. - Legacy applications can receive modern MFA protection without code changes. - Cloudflare’s independent MFA is currently in closed beta. ## Reducing Attack Impact - Requiring authentication before Internet access ensures managed devices remain registered and visible. - Independent MFA reduces the blast radius of stolen passwords or compromised SSO sessions. - Cloudflare positions these capabilities as part of a broader move toward continuous, automated security posture enforcement. Organizations using Cloudflare One should consider mandatory authentication for managed endpoints and independent, risk-based MFA for sensitive applications.

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

Figma Expands Support for India with Local Data Hosting and New Governance Tools | Figma Blog (opens in new tab)

Figma is expanding its support for India with local hosting for Figma file data and stronger enterprise governance tools. Local data residency is planned for Q1 2026, helping regulated organizations meet security and compliance requirements while maintaining Figma’s performance. Governance+ is already available to Enterprise customers in India. ## Local Data Hosting for Indian Customers - Figma file data will be hosted within India, including content from FigJam, Make, Sites, Buzz, and Slides. - The option is intended for regulated sectors such as public services, healthcare, and finance. - Indian users created more than 35 million files between October 2024 and September 2025. - India is Figma’s second-largest active user base globally. - The offering builds on existing data residency options in Australia, Europe, and the United States. - Figma has expanded its local presence through a new Bengaluru hub and serves companies including Airtel, Flipkart, Swiggy, TCS, and Zomato. ## Governance+ for Enterprise Teams Governance+ gives organizations more control over how employees access and use Figma: - **Centralized control:** IP Allowlisting and Network Access Restrictions help ensure work occurs in approved Figma instances and networks. - **Account security:** Enforced two-factor authentication, extended idle session timeouts, and support for multiple identity providers reduce account-compromise risks. - **Data governance:** The Discovery Pipeline provides visibility into activity to support retention policies and legal discovery. - Governance+ complements existing tools such as activity logs, SSO, SCIM-based seat management, and restrictions on external collaborators. - The feature is available now to all Enterprise-plan customers. Figma’s India strategy combines regional data residency with tighter administrative controls, making the platform more suitable for organizations with strict privacy, security, and regulatory obligations. Enterprises interested in local hosting can register their interest ahead of its planned Q1 2026 launch.

figma

Figma Deepens Roots in Australia with Local Data Hosting | Figma Blog (opens in new tab)

Figma is expanding its investment in Australia by introducing enterprise governance features and local hosting for Figma file data. Starting in Q4 2025, Australian customers will be able to store data locally, supporting organizations with strict security and compliance requirements. The move strengthens Figma’s position among regulated industries and marks its first data-residency offering in Asia Pacific. ## Local Data Hosting in Australia - Figma will host file data locally in Australia, including content from: - Figma - FigJam - Make - Sites - Buzz - Slides - Local hosting is intended for industries such as: - Government and the public sector - Healthcare - Financial services - The option provides greater control over data location while preserving Figma’s platform capabilities and scalability. - Australia is Figma’s first local data-hosting market in Asia Pacific, extending similar enterprise offerings already available in Europe and the United States. - Figma opened its Sydney office in November 2024 and serves customers including NAB, Safety Culture, and Atlassian. ## Governance+ for Enterprise Customers Governance+ gives enterprises more control over how employees access and use Figma. - **Centralized controls** - Enforce use of approved Figma instances and networks. - Use IP Allowlisting and Network Access Restrictions to prevent data from moving into unauthorized spaces. - **Account security** - Require two-factor authentication. - Extend idle session timeouts. - Support for multiple SSO configurations is planned. - **Data governance** - Monitor Figma activity through tools such as the Discovery Pipeline. - Support electronic communications retention and legal discovery requirements. ## Existing Enterprise Security Features Governance+ builds on existing enterprise capabilities, including: - Action logs - SAML single sign-on - Role assignments connected to identity-management systems - Restrictions on external collaborators joining an organization Governance+ is available now to customers on Figma’s Enterprise plan. Figma’s Australian data residency option will be particularly useful for organizations that must meet local storage, privacy, and regulatory obligations. Enterprise customers can adopt Governance+ immediately and register interest in local hosting ahead of its planned Q4 2025 launch.