Skip to main content
When a user signs in through SAML SSO, EK receives SAML metadata attributes (for example department, group, or role). The Access Controls feature uses those attributes to determine whether a user is permitted to enter the application at all.
Access Controls and Automated Team Management are independent features, but they are typically used together. See Automated Team and Project Assignment for the companion guide.

​
Prerequisites

Before enabling access controls:
  • SAML SSO must be configured and being sent metadata attributes on login
  • The SAML assertion must include stable attributes to match against
Validate attribute names and values from a few successful SSO logins before enabling any restrictions.

​
Access Modes

Navigate to Super Admin → Access Controls to select a mode. Access Mode Selection
ModeBehavior
Allow Any New UsersDefault. Email/password, Google OAuth, and SSO signups are all permitted.
Restrict to SAML MetadataOnly SSO users whose SAML attributes match at least one configured rule are allowed.

​
How Rule Matching Works

Rules are defined by an Attribute Name and an Attribute Value. SAML Access Rules
  • Logic is OR — any single rule match grants access
  • Comparison is case-insensitive
  • Leading/trailing spaces are ignored
  • Matching is exact-value (not partial or contains)

​
Behavior When Restricted Mode is Active

  • New email/password registrations
  • New Google OAuth registrations
  • New SSO users whose SAML attributes do not match any rule
  • Existing SSO users who match at least one rule (re-checked on every sign-in)
  • Existing local users signing into existing accounts
  • Super Admin accounts via SSO, even without a matching rule
Fail-open behavior: If restricted mode is ON but no SAML access rules exist, AAEKB allows all SSO users. This prevents accidental lockout, but you should always define at least one rule before enabling strict governance.

​
Configure Access Controls

1

Open Access Controls

Go to Super Admin → Access Controls.
2

Select Restricted Mode

Choose Restrict to SAML Metadata.
3

Add SAML Access Rules

Add one or more rules under SAML Access Rules. Examples:
department = engineering
group = ekb-users
4

Save and Validate

Save your rules and test with representative SSO accounts before rolling out broadly.
  1. Create rules while mode is still set to Allow Any New Users
  2. Validate with pilot SSO accounts
  3. Switch to Restrict to SAML Metadata
  4. Monitor sign-ins and access-denied outcomes

​
Testing Checklist

After configuration, verify each scenario:
  • An SSO user who should be allowed can sign in
  • An SSO user who should not be allowed is redirected to the access-denied experience
  • Denied users see the expected access-denied experience
  • At least one valid rule is active to avoid policy drift

​
Troubleshooting

  • Confirm access mode is not unintentionally set to restricted
  • Verify the rule uses the correct attribute name and exact expected value
  • Confirm the IdP is sending that attribute for that user
  • Check whether the user is attempting email/password or Google OAuth login while restricted mode is active
Super Admin accounts are always allowed through SSO even without a matching rule. If locked out, sign in via SSO using a Super Admin account to regain access.

​
Operational Guidance

  • Treat access rules as security-sensitive configuration
  • Use change management processes for production updates
  • Re-test after any IdP claim changes
  • Periodically review rules and remove stale mappings
  • Keep at least one valid rule active to prevent unintended fail-open states