Skip to main content

Identity and Access Management (IAM)

Proper Identity and Access Management (IAM) is the cornerstone of a robust security strategy, ensuring the right identities have the appropriate level of access at the right time. This section provides the core control objectives for configuring user authentication and authorization.

Core Principle: Centralize Control via Guidewire Hub​

The Guidewire Identity Federation Hub (Guidewire Hub) is the central authority for identity and access control across the Guidewire Cloud Platform. All identity and access control measures should be managed through this single, trusted authority to enforce your organization's security policies.

Principle 1: Enforce Strong, Centralized Authentication​

Your corporate identity provider (IdP) is the single source of truth for all user authentication.

  • Control Objective: All users should access Guidewire applications through Single Sign-On (SSO) linked to your corporate IdP (for example, Azure AD, Okta).
    • Example: Without SSO, an employee might have separate logins for PolicyCenter, BillingCenter, and ClaimCenter. With SSO, users log in once using their corporate credentials and gain seamless access to all the Guidewire applications for which they are authorized.
  • Control Objective: We strongly recommend that Multi-Factor Authentication (MFA) be enforced for all users, without exception. This policy should be enforced at the IdP level.
  • Control Objective: Your IdP should be configured to enforce strong password policies, including requirements for complexity, rotation, and history.

Principle 2: Build Roles Based on Least Privilege​

The most common source of privilege escalation risk in InsuranceSuite stems from the misuse of out-of-the-box (OOTB) sample data.

Question: What is a leading cause of user role misconfiguration, and what is the recommended practice for managing the out-of-the-box (OOTB) sample roles?

Answer: A primary cause of role-based access control (RBAC) misconfiguration stems from the default sample roles included in InsuranceSuite's base data. These roles are provided for demonstration purposes and often contain an excessive or inappropriate combination of permissions that do not align with the principle of least privilege. Leaving these sample roles active in a production environment introduces a significant security risk. Therefore, it is a strongly recommended security practice to create custom roles and eliminate the OOTB sample roles before go-live.

The recommended procedure is as follows:

  1. Audit & Define: During initial development, audit the OOTB roles to understand the available permissions and define your own custom roles based on your organization's specific job functions.
  2. Build with Least Privilege: Create new custom roles from scratch, granting only the minimum permissions necessary for each role. Do not clone OOTB roles.
  3. Deactivate & Remove: Before go-live, ensure all OOTB sample roles are unassigned and then deactivated or deleted.
  4. Verification: Your pre-go-live security audit should confirm that no OOTB sample roles remain active or assigned.

Principle 3: Manage the Full User Account Lifecycle​

You should manage the entire lifecycle of user accounts to prevent unauthorized access from orphaned or unnecessary accounts.

  • Control Objective: You should implement an automated process for timely user deprovisioning using current platform capabilities, such as integrating your Identity Provider (IdP) with InsuranceSuite's system APIs. We strongly recommend having this automated process in place at go-live.
    • Example: When an employee leaves the company, your automated process, linked to your IdP, immediately triggers an API call to revoke their access to all Guidewire applications. This eliminates the risk of a former employee accessing sensitive data.
  • Control Objective: All non-essential default, test, or sample user accounts should be disabled or removed from the system before go-live.

Principle 4: Apply Strict Controls to Privileged Access​

All accounts with administrative permissions should be tightly controlled.

  • Control Objective: The UnrestrictedUser, which bypasses all permission controls, should be severely restricted to specific, documented "break-glass" scenarios, and all its activity should be closely monitored.
  • Control Objective:: All default administrative credentials should be changed immediately upon deployment.
    • Cautionary Example: A widely known historical default in Guidewire was the su/gw credential. While this specific user is deprecated in modern configurations, the principle is timeless: default credentials are a primary target for attackers. Your security plan should include a discovery and remediation step to ensure no such defaults exist in your production environment.
  • Control Objective: Assigning superuser-level rights to regular users for daily tasks is not a recommended practice.

Principle 5: Secure All System-to-System Communications​

All system-to-system communications should be authenticated and secured.

  • Control Objective: All integrations and API connections should authenticate using the OAuth 2.0 protocol. Using static credentials or API keys in configuration files is not a recommended practice.
    • Example: When ClaimCenter calls an external vehicle valuation service via API, it uses an OAuth 2.0 token to prove its identity. This is more secure than embedding a static password in a configuration file, as the token is short-lived and specific to that function.
  • Control Objective: The Secure Gateway and Integration Gateway (IG) should be configured precisely as outlined in the Guidewire Go-Live checklists.

Resources​

Guidewire Security Hub:

Guidewire Cloud Standards:

Guidewire Documentation:

Legal and Support Information
Copyright © 2001-2025 Guidewire Software, Inc.