GreenLake's Personal API Clients enable programmatic access for automation workflows like scheduled tasks, CI/CD pipelines, monitoring systems, and infrastructure-as-code tools. A service user is a regular user account dedicated to automation rather than a human operator, providing stable credentials that outlive individual employees and projects. Service users authenticate using either Self-Service (local platform password) or SSO (IdP authentication), and can optionally be provisioned via SCIM for automated lifecycle management.
This guide complements Identity Governance Essentials and Workspace Architecture Guide with practical patterns for API client management.
When automation depends on personal credentials, it breaks when employees leave, change roles, reset passwords, or update MFA settings. Service users provide the stable, long-lived identity that automation requires.
| Challenge | Without Service Users | With Service Users |
|---|---|---|
| Personnel Changes | Automation breaks when employees leave; credentials must be recreated and redistributed | Distribution list ownership ensures team continuity regardless of staff turnover |
| Permission Stability | Human role changes ripple into unrelated automation; excessive troubleshooting required | Dedicated identity with stable, least-privilege permissions isolated from organizational changes |
| Audit & Compliance | Automated actions attributed to individuals; difficult to distinguish human from machine activity | Clear service identity in audit logs; simplified compliance reporting and access reviews |
| Credential Security | Credentials shared informally across teams or embedded in code; high breach risk | Controlled lifecycle with secrets manager storage, rotation policies, and centralized revocation |
| Operational Fragility | Password resets, MFA changes, account suspensions disrupt production automation | Independent lifecycle management decoupled from human user events |
| Identity Governance | Manual tracking across multiple systems; difficult to audit non-human access patterns | Service users integrate naturally with IdP workflows, SCIM provisioning, PAM tools, and IGA platforms for centralized governance |
| Permission Management | Each automation requires individual role assignments; revocation requires touching multiple users | Add to user groups for centralized permission management; update once at group level |
Setting up service users follows a straightforward pattern:
That's the core pattern. The sections below help you choose the right authentication model and implement security best practices.
| Your Situation | Authentication | Provisioning | Key Benefit |
|---|---|---|---|
| Getting started, exploring GreenLake | Self-Service | Manual | Simplest setup, no prerequisites |
| Organization hierarchy with SSO | SSO | Manual or SCIM | IdP authentication, centralized identity |
| Production with compliance requirements | Self-Service or SSO | SCIM | Automatic lifecycle, audit-ready |
| MSP managing customer tenants | Match tenant (Self-Service or SSO) | SCIM for MSP parent | Operational control + tenant flexibility |
Evolution Path: Self-Service and Manual (exploration) → SSO and Manual (organization hierarchy) → SSO and SCIM (production and compliance).
Service user implementation combines two independent choices: authentication method (how users sign in) and provisioning approach (how user lifecycle is managed).
SSO authentication and SCIM provisioning require an organization hierarchy (enterprise or MSP parent workspace). Standalone workspaces support only Self-Service authentication (HPE MyAccount) with manual provisioning.
| Feature | Self-Service + Manual | Self-Service + SCIM | SSO + Manual | SSO + SCIM |
|---|---|---|---|---|
| Authentication | Admin-managed password stored on platform | Admin-managed password stored on platform | Organization's IdP (SSO) | Organization's IdP (SSO) |
| User Lifecycle | Manual creation, manual deprovisioning | Automatic SCIM provisioning/deprovisioning | JIT creation on first sign-in, manual deprovisioning | Automatic SCIM provisioning/deprovisioning |
| Password Management | Managed locally on platform | Managed locally on platform | Managed by IdP (no platform password) | Managed by IdP (no platform password) |
| Credential Revocation | Manual per-workspace | Automatic on SCIM deprovisioning (removes all credentials and roles) | Manual per-workspace | Automatic on SCIM deprovisioning (removes all credentials and roles) |
| MFA Availability | Platform MFA optional (recommended) | Platform MFA optional (recommended) | IdP MFA policies apply (if configured) | IdP MFA policies apply (if configured) |
| Audit Integration | Platform audit logs only | Platform audit logs only | IdP audit logs + platform logs | IdP audit logs + platform logs |
| Setup Complexity | Low | Medium | Medium | High |
| Best For | Standalone workspaces, exploration, proof-of-concept | Compliance environments without SSO | Organizations with SSO, manual lifecycle acceptable | Production with compliance and automated lifecycle (Recommended) |
Self-Service Authentication: Users authenticate with admin-managed password stored on GreenLake. Platform MFA controls apply. Available in standalone workspaces and organization hierarchies.
SSO Authentication: Users authenticate via organization's Identity Provider (IdP). IdP MFA policies enforced. No platform password needed. Requires organization hierarchy (enterprise or MSP parent workspace).
Manual Provisioning: Administrator creates users via console. Manual deprovisioning required (credentials must be revoked per-workspace). Available with Self-Service or SSO authentication.
SCIM Provisioning: Identity Provider automatically provisions users to GreenLake via SCIM protocol. When deprovisioned in IdP, SCIM automatically removes platform user, revokes all API credentials, and removes all role assignments across all workspaces. Works with Self-Service authentication (local password) OR SSO authentication (IdP). Requires organization hierarchy with SCIM configured.
SCIM is an API-based provisioning standard. While typically driven by your IdP, administrators can also call the SCIM API directly using their own credentials for programmatic user management.
Self-Service + Manual (Simplest)
- When: Standalone workspaces (only option), exploration, proof-of-concept, organizations without organization hierarchy
- Pros: Simplest setup, no IdP dependency, platform MFA available
- Cons: Manual lifecycle management, password managed separately from IdP, limited audit integration
SSO + Manual (IdP Integration)
- When: Organization hierarchies with SSO configured, IdP MFA enforcement needed, manual lifecycle acceptable
- Pros: No platform password, IdP MFA enforcement, centralized identity, consolidated audit logs
- Cons: No automatic deprovisioning when disabled in IdP, manual per-workspace revocation required
Self-Service + SCIM (Automated Lifecycle without SSO)
- When: Compliance environments requiring automated lifecycle but without SSO capability
- Pros: Automatic deprovisioning, compliance-ready lifecycle management, platform MFA available
- Cons: Requires SCIM configuration, platform password management, IdP dependency for provisioning
SSO + SCIM (Full Enterprise Integration) Recommended for Production
- When: Production environments in organization hierarchies requiring compliance (HIPAA, SOC2, PCI DSS)
- Pros: Automatic deprovisioning, no platform password, IdP MFA enforcement, consolidated audit logs, compliance-ready lifecycle
- Cons: Higher setup complexity, requires both SSO and SCIM configuration, IdP dependency
When a user is deprovisioned via SCIM, the platform automatically removes all credentials and all role assignments in all workspaces. For more granular access control, assign access via user groups and manage service user permissions by adding/removing them from groups rather than deprovisioning the user entirely.
We strongly recommend SCIM Provisioned Users for production environments requiring high security and compliance. The automatic lifecycle management eliminates the risk of orphaned credentials and satisfies audit requirements for access governance.
Organizations with mature security programs often supplement service user management with:
PAM (Privileged Access Management): Vaults credentials, automates rotation, provides session recording. Adopt when managing 10+ high-privilege service users or compliance mandates credential vaulting (PCI DSS, SOC2, FedRAMP).
IGA (Identity Governance and Administration): Orchestrates access reviews, detects privilege creep, enforces separation-of-duties. Adopt when managing 20+ service users across multiple systems or compliance requires quarterly access certification.
Integration: SCIM handles provisioning/deprovisioning, PAM secures credential storage and rotation, IGA enforces governance policies and access reviews. Start with SCIM, add PAM/IGA when scale or compliance justifies investment.
| Configuration Area | Key Principle | Rationale |
|---|---|---|
| User Email | Distribution list or shared mailbox | Prevents automation breakage when personnel change |
| Password | Strong random password in shared password manager | Enables team access without individual dependency |
| MFA (Optional, Recommended) | See detailed guidance below | Significantly reduces credential compromise risk |
| Role Assignment | Least privilege via roles + user groups | Simplifies permission management and enables quick revocation |
| Credential Storage | Infrastructure secrets manager (cloud or on-premises vault) | Prevents embedding in code, enables audit logging |
| Credential Injection | Runtime environment variables | Never commit secrets to version control |
| Rotation Policy | Risk-based schedule per organizational security standards | Reduces exposure window for compromised credentials |
| Audit Trail | Service user identity in logs | Distinguishes automated from human actions |
| Lifecycle Tracking | Centralized inventory with regular review | Identifies unused service users and enforces rotation compliance |
Use a distribution list (email forwarding to multiple recipients) or shared mailbox (shared inbox access) instead of individual employee email addresses to prevent automation breakage when personnel change.
- Naming Convention: Use clear integration identifiers like
svc-terraform-ci@yourorganization.com,bot-reporting@yourorganization.com - Mailbox Management: Forward to 2-3 technical stakeholders to ensure password resets and security alerts reach the team
Never use a personal email address (john.doe@yourorganization.com) for service users. When that employee leaves, automation credentials become unrecoverable if password reset emails are lost.
Console access is required initially to generate API credentials. Secure this entry point:
- Generate a strong random password using a password manager, following your organization's password complexity standards.
- Store it in an enterprise password manager shared with authorized team members.
- MFA is not mandatory for service users, but it significantly reduces the risk of credential compromise.
- MFA availability and enforcement depend on your identity model:
| Identity Model | MFA Availability | Team Access Strategy |
|---|---|---|
| Self-Service Users | Platform MFA optional (strongly recommended) | Team-shared MFA using TOTP seed storage (see guidance below) |
| SSO Managed Users | IdP MFA policies apply (if configured) | Managed by your organization's IdP configuration |
| SCIM with local auth | Platform MFA optional (strongly recommended) | Team-shared MFA using TOTP seed storage (see guidance below) |
| SCIM with SSO | IdP MFA policies apply (if configured) | Managed by your organization's IdP configuration |
GreenLake authentication supports multiple MFA methods. Available options include (but are not limited to):
- Okta Verify - TOTP or push notification support
- Google Authenticator - TOTP standard compatible
- Security Key or Biometric Authenticator - FIDO2/WebAuthn hardware or biometric verification
Specific MFA options may change over time.
For service users requiring platform MFA (Self-Service or SCIM with local authentication), implement team access using these approaches:
TOTP-Based Methods (Okta Verify TOTP, Google Authenticator):
Store the MFA seed (secret key) in your enterprise password manager during enrollment. Multiple team members can then generate synchronized one-time codes from the same seed without device dependencies.
| Approach | Implementation | Team Access | Security Considerations |
|---|---|---|---|
| Enterprise Password Manager | Store MFA seed during enrollment | Team members retrieve seed and generate codes on their devices | Seed storage must follow organization's secrets management policies; access control via password manager permissions |
| PAM Vault Integration | Vault stores password + MFA seed together | PAM system injects credentials and generates codes automatically | Highest security; requires privileged access management tooling; supports session recording and approval workflows |
Hardware Security Key (FIDO2/WebAuthn):
Physical key remains with designated team members. Practical for small teams with established key custody procedures.
| Approach | Implementation | Team Access | Security Considerations |
|---|---|---|---|
| Dedicated Security Key | Enroll hardware key during setup | Key custody rotates among authorized team members | Secure key storage (locked cabinet, safe); document key location and custody chain; backup enrollment recommended |
Push-Based Methods (Okta Verify Push):
Requires mobile device enrollment. Not recommended for service users due to device dependency - use TOTP or hardware keys instead for team accessibility.
Password manager and PAM examples (1Password, CyberArk, HashiCorp Vault) illustrate capabilities, not endorsements. Select tools that meet your organization's security standards and procurement requirements.
Console login is required initially to generate Personal API Client credentials. After credential generation, service users typically interact only via API. However, you should have secure console access for credential rotation and troubleshooting.
Assign only the permissions necessary for specific automation tasks. Avoid "Administrator" roles unless required.
Role Assignment Options:
- Read-only roles for monitoring and reporting
- Service-specific roles for infrastructure management
- Workspace-scoped roles for single-workspace automation
Group-Based Access Management Strongly Recommended:
User groups enable centralized permission management and should be your default approach:
- Update permissions once at the group level (affects all group members)
- Group names document purpose (e.g., "Automation-Terraform-Production")
- New service users inherit permissions immediately upon group addition
- Remove from group for instant revocation without deprovisioning user
SCIM Group Synchronization: With SCIM Provisioned Users, group memberships can be managed directly in your IdP. Add or remove service users from groups in your IdP and SCIM automatically synchronizes changes to GreenLake. This enables centralized access governance, automated role assignment workflows, and consistent permission enforcement across all integrated systems without manual platform updates. SCIM group synchronization works regardless of whether SSO is configured.
Examples:
- Terraform: Add
svc-terraform-prod@company.comto "Automation-Infrastructure-Prod" group - Monitoring: Add
svc-monitoring@company.comto "Automation-Observability" group - Backup: Add all backup service users to "Automation-Backup" group
Secure Storage: Store Client Secrets immediately in infrastructure secrets managers (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, or similar). Enable audit logging and restrict retrieval to authorized automation infrastructure.
Runtime Injection: Inject credentials at runtime via environment variables. Never embed in version control, application code, Terraform files, container images, or CI/CD definitions.
Credential Rotation: Establish rotation policy based on your organization's security standards and risk assessment. High-privilege service users (workspace administrators) require more frequent rotation than read-only monitoring users. Document and test rotation procedures before they are needed in an emergency.
Never commit Client Secrets to version control. Even deleted commits remain in Git history. Use .gitignore and pre-commit hooks to prevent accidental exposure.
Audit Trail: API actions are attributed to the service user identity (for example, svc-terraform-ci@yourorganization.com), distinguishing automated from human actions. Review logs regularly for anomalous behavior.
Lifecycle Tracking: Maintain inventory with purpose, owning team, workspaces, roles, and rotation schedule. Review quarterly to retire unused service users.
Once you've chosen your authentication and provisioning model, follow this comprehensive workflow:
- Select Authentication & Provisioning - Choose authentication method (Self-Service or SSO) and provisioning approach (manual or SCIM) based on your workspace hierarchy and compliance requirements
- Create Service User - Provision user identity following your selected model (HPE MyAccount, IdP with JIT creation, or SCIM provisioning)
- Configure Security - Set distribution list email, strong password in shared password manager, and team-accessible MFA (TOTP seed storage or hardware key)
- Assign Permissions - Apply least privilege roles and add to user groups for centralized permission management
- Generate API Credentials - Sign in to console and create Personal API Client (Client ID and Client Secret)
- Secure Credentials - Store Client Secret immediately in infrastructure secrets manager (never commit to version control)
- Implement Runtime Injection - Configure automation to retrieve credentials from secrets manager and inject via environment variables
- Document and Track - Add service user to centralized inventory with purpose, owning team, workspaces, rotation schedule
- Monitor and Maintain - Review audit logs regularly, perform quarterly inventory reviews, test incident response procedures
Service user management varies by workspace architecture. See Workspace Architecture Guide for complete guidance.
User Identity: Self-Service authentication only (HPE MyAccount). No SSO or SCIM available. Create the service user once in HPE MyAccount, then workspace administrators invite that user to each standalone workspace via console. This is a fully manual, interactive process with no API for programmatic management.
API Client Credentials: After service user accepts invitation to each workspace, sign in as the service user to create Personal API Client credentials separately in each standalone workspace. Each workspace administrator controls role assignments for API clients in their workspace.
Limitations: No centralized directory, no automated lifecycle management, no API for user provisioning. While the same service user identity can be invited to multiple standalone workspaces, all invitation and credential management must be performed manually per workspace. Because there is no programmatic provisioning, maintain a manual record of each service user - its purpose, owning team, every workspace it was invited to, assigned roles, and credential rotation schedule. See Service user inventory management.
Architecture (see diagram): Organization parent provides shared directory. Member workspaces inherit user identities.
User Identity: Create service user once in the organization parent's shared directory. User identity automatically propagates to all member workspaces. SCIM provisioning strongly recommended for production.
API Client Credentials: Generate Personal API Client credentials separately in each member workspace where automation needs access. The same service user identity can have different API client credentials (with different role assignments) in each member workspace, enabling workspace-specific least privilege controls.
Example: Service user svc-terraform-prod@company.com is created once in organization parent. To automate infrastructure in three member workspaces (Dev, Staging, Production), sign in as this user to each workspace console and generate separate API client credentials per workspace:
- Dev workspace: API Client with read-only roles
- Staging workspace: API Client with infrastructure management roles
- Production workspace: API Client with infrastructure management roles
Each workspace administrator controls what roles are assigned to that workspace's API client credentials.
Benefit: Centralized user lifecycle management (single identity, SCIM deprovisioning) combined with workspace-scoped permission boundaries.
Architecture (see diagram): MSP parent manages provider operations. Customer tenant workspaces maintain independent identity boundaries.
MSP Operational Service Users: Provision service users at MSP parent level for MSP operational automation.
API Client Credentials - Token Exchange Key MSP Capability: MSPs create Personal API Client credentials once in the MSP parent workspace and use OAuth 2.0 Token Exchange to obtain tenant-specific access tokens dynamically. This single-credential-set pattern is a critical operational efficiency - it eliminates the need to create, rotate, and secure separate credentials in each tenant workspace.
- Generate MSP workspace-scoped access token using MSP API client credentials
- Exchange that token for tenant-specific tokens as needed
- Maintain single set of credentials while accessing multiple tenant workspaces
For complete token exchange implementation guidance, see MSP Access Token Exchange.
Customer-Specific Service Users: Customer tenant administrators provision service users within their own tenant workspaces using their identity model (Self-Service, SSO, or SCIM). Customer service users create API client credentials in their tenant workspace following standard patterns (one user identity, separate API clients per workspace if customer has multiple workspaces).
Inventory Management: Maintain separate service user inventories - one for MSP operational users, separate inventories per customer tenant.
See Identity Governance Essentials - MSP Patterns for complete MSP identity governance guidance.
Maintain a centralized inventory of all service users with:
When creating service users, set descriptive First Name and Last Name fields (e.g., "Terraform" / "CI Production") instead of generic placeholders. These names appear in audit logs, permission reports, and user listings, making it easier to identify service user purpose without looking up email addresses.
| Field | Purpose | Example |
|---|---|---|
| Service User Email | Unique identifier | svc-terraform-prod@company.com |
| Integration Purpose | What automation uses this service user | "Production Terraform CI/CD pipeline for compute resources" |
| Owning Team | Who is responsible | "Platform Engineering - DevOps Team" |
| Primary Contacts | Distribution list recipients | devops-leads@company.com |
| User Groups | Groups providing permissions | "Automation-Infrastructure-Prod, Automation-API-Clients" |
| Workspaces Assigned | Where service user has access | "Production Member Workspace (via Automation-Infrastructure-Prod group)" |
| Credential Rotation Schedule | When credentials must be rotated | "Every 90 days - next rotation 2025-03-15" |
| Last Rotation Date | Tracking compliance | "2024-12-15" |
| Provisioning Model | Self-Service, SSO, or SCIM | "SCIM Provisioned" |
| Decommission Date | Planned retirement (if applicable) | "2025-06-30 (project completion)" |
Quarterly Maintenance: Review inventory, retire unused service users, verify rotation compliance, update contacts, test revocation procedures.
See docs for credential rotation Reset the secret of a credential.
Pre-Rotation: Schedule maintenance window, notify teams, verify backup console access, document current Client ID
Execution: Generate new credentials, update secrets manager, test in non-production, deploy to production, verify functionality
Post-Rotation: Revoke old credentials, update inventory, document issues
If credentials are compromised:
- Revoke credentials:
- SCIM with group-based access: Remove from user groups for granular revocation
- SCIM deprovisioning: Disable in IdP (removes all credentials and roles)
- SSO/Self-Service: Manual revocation in all workspaces
- Reset password and rotate MFA
- Review audit logs for unauthorized activity
- Generate new credentials and update automation
- Document incident
If the service user owner leaves:
- Service user remains active (distribution list ownership ensures continuity)
- Update inventory contacts and transfer password manager ownership
- For access changes: Remove from user groups (preferred) or deprovision via SCIM/manual
Before deploying service users to production, verify:
- Service user uses distribution list or shared mailbox email (not personal email)
- Strong random password generated and stored in shared password manager
- If implementing MFA (optional, recommended): Seed stored securely for team access (Self-Service users) or IdP MFA configured (SSO users)
- Least privilege role assigned (not Administrator unless required)
- Role scoped to minimum required workspaces
- Service user added to appropriate user groups for centralized permission management (when applicable)
- Personal API Client credentials stored in infrastructure secrets manager
- Credentials never committed to version control
- Credentials injected at runtime via environment variables
- Credential rotation policy defined and documented
- Service user added to centralized inventory
- Owning team and contacts documented
- Audit logging enabled and monitored
- SCIM provisioning enabled (for production environments)
- Decommissioning procedure documented
- Incident response plan includes service user scenarios
- Identity Governance Essentials - Domain claiming, SSO, SCIM, and centralized user management
- Workspace Architecture Guide - Workspace design patterns and service consolidation strategies
- GreenLake Organization and Enhanced IAM Management User Guide (HPE Support Center) - Step-by-step procedures for user creation, role assignment, and Personal API Client generation
Service Users enable secure automation in GreenLake:
- Use distribution lists for email addresses
- Implement least privilege via roles and user groups
- Secure credentials in secrets managers with runtime injection
- Choose provisioning model: SCIM (production), SSO (IdP integration), self-service (development)
- Maintain inventory with rotation schedules
- Document incident procedures
These practices create automation that is resilient to personnel changes, secure against compromise, and compliant with governance requirements.