external/anthropic-cybersecurity-skills/skills/implementing-google-workspace-sso-configuration/SKILL.md
Configure SAML 2.0 single sign-on for Google Workspace with a third-party identity provider, enabling centralized authentication and enforcing organization-wide access policies.
npx skillsauth add seikaikyo/dash-skills implementing-google-workspace-sso-configurationInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Single Sign-On (SSO) for Google Workspace allows organizations to authenticate users through their existing identity provider (IdP) such as Okta, Azure AD (Microsoft Entra ID), or ADFS, rather than managing separate Google passwords. This is implemented using SAML 2.0 protocol where Google Workspace acts as the Service Provider (SP) and the organization's IdP handles authentication. SSO centralizes credential management, enforces MFA policies at the IdP, and enables immediate access revocation when users leave the organization.
User navigates to Google Workspace app (Gmail, Drive, etc.)
│
├── Google checks: Is SSO configured for this domain?
│
├── YES → Redirect user to IdP Sign-In Page URL
│ (SAML AuthnRequest sent via browser redirect)
│
├── User authenticates at IdP (credentials + MFA)
│
├── IdP generates SAML Response with signed assertion
│
├── Browser POSTs SAML Response to Google ACS URL:
│ https://www.google.com/a/{domain}/acs
│
├── Google validates SAML signature against uploaded certificate
│
└── User is granted access to Google Workspace
| Parameter | Value |
|-----------|-------|
| ACS URL | https://www.google.com/a/{your-domain}/acs |
| Entity ID | google.com/a/{your-domain} or google.com |
| NameID Format | urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress |
| NameID Value | User's primary Google Workspace email |
| Binding | HTTP-POST (for ACS), HTTP-Redirect (for SSO URL) |
For Okta:
For Azure AD (Microsoft Entra ID):
google.comhttps://www.google.com/a/{your-domain}/acshttps://www.google.com/a/{your-domain}/ServiceLoginFor ADFS:
Third-Party SSO Profile Settings:
| Setting | Value |
|---------|-------|
| Set up SSO with third-party IdP | Enabled |
| Sign-in page URL | IdP's SAML SSO endpoint (e.g., https://idp.example.com/sso/saml) |
| Sign-out page URL | IdP's logout URL (e.g., https://idp.example.com/slo) |
| Change password URL | IdP's password change URL |
| Verification certificate | Upload IdP's X.509 signing certificate |
| Use a domain-specific issuer | Enabled (uses google.com/a/{domain} as entity ID) |
SSO profiles can be applied at different scopes:
Organization-wide (all users)
│
├── Org Unit level (specific departments)
│ ├── Engineering OU → SSO via Okta
│ ├── Marketing OU → SSO via Azure AD
│ └── Contractors OU → SSO via specific IdP
│
└── Group level (specific security groups)
└── VPN Users → SSO with additional MFA
Network masks control when SSO is enforced based on the user's IP:
This is useful for allowing direct Google login from corporate network while enforcing SSO for external access.
https://mail.google.com/a/{your-domain}tools
Zero-Knowledge Proofs (ZKPs) allow a prover to demonstrate knowledge of a secret (such as a password or private key) without revealing the secret itself. This skill implements the Schnorr identificati
development
Configure ModSecurity WAF with OWASP Core Rule Set (CRS) for web application logging, tune rules to reduce false positives, analyze audit logs for attack detection, and implement custom SecRules for application-specific threats. The analyst configures SecRuleEngine, SecAuditEngine, and CRS paranoia levels to balance security coverage with operational stability. Activates for requests involving WAF configuration, ModSecurity rule tuning, web application audit logging, or CRS deployment.
development
Build automated alerting for vulnerability remediation SLA breaches with severity-based timelines, escalation workflows, and compliance reporting dashboards.
testing
Vulnerability remediation SLAs define mandatory timeframes for patching or mitigating identified vulnerabilities based on severity, asset criticality, and exploit availability. Effective SLA programs