Skip to content

Access Requests and Delegated Administration Guide

This guide provides comprehensive instructions for tenant administrators on managing access requests, self-service workflows, and delegated administration through the Auth service UI.

Table of Contents

Overview

The Access Requests section enables self-service and delegated access management:

  • Self-service access: Users request access; approvers grant or deny
  • Delegated administration: Empower non-admins to manage specific resources
  • Time-limited access: Automatic expiration for temporary permissions
  • Audit trail: Complete record of access grants and approvals
  • Bulk operations: Efficiently onboard groups of users

Security philosophy: Access Requests implements the principle of least standing privilege by enabling:

  • Just-in-time access (request when needed, not granted permanently)
  • Time-limited grants (automatic expiration)
  • Peer approval (non-admin managers can approve)
  • Self-service (reduces admin bottlenecks)

Access Requests Menu Options

View Access Requests

Location: Access Requests > View Access Requests

Purpose: Central dashboard for viewing, creating, approving, and rejecting access requests.

What you can do

  • View all access requests: See pending, approved, and rejected requests
  • Create access requests: Submit new requests on behalf of users
  • Review requests: Examine request details before approval
  • Approve requests: Grant access to approved requests
  • Reject requests: Deny access with reason
  • Filter and search: Find specific requests by user, status, date range, or resource

Request Table Columns

  • Access Request Name: The template name for this request
  • User: Email of user requesting access
  • Resource ID: Identifier of the requested resource
  • Request Date: When request was submitted
  • Expired: Whether the request has expired
  • Request Expiration Date: When request expires if not approved
  • Status: pending, approved, or rejected
  • Details: Click to view full request details and take action

Filtering Access Requests

Status filter:

  • Pending: Awaiting approval
  • Approved: Access has been granted
  • Rejected: Access was denied
  • Any: Show all requests

Expiration filter:

  • Expired: Requests past their approval deadline
  • Not Expired: Active requests still awaitable approval
  • Any: Show all

Date range filter:

  • Filter by request creation date
  • Presets: Today, Yesterday, Last 7/30 days, This/Last Month
  • Custom range: Select start and end dates

Search: Free-text search across request name, user, and access type

Request Lifecycle

  1. Submitted: User or admin creates an access request
  2. Pending: Request awaits approval from authorized approver
  3. Approved: Approver grants access
  4. User/group is added to target group or granted UMRS role
  5. Access becomes active immediately
  6. Rejected: Approver denies access
  7. No permissions granted
  8. User notified of rejection
  9. Expired: Request deadline passed without approval
  10. Request cannot be approved after expiration
  11. User must submit a new request

Creating an Access Request

  1. Click + ADD NEW button
  2. Select user who needs access
  3. Choose access template (pre-configured by admin)
  4. Provide justification (optional)
  5. Submit request
  6. Request appears in pending state for approvers

Use case: Admin creates request on behalf of user who doesn't have self-service access.

Approving/Rejecting Requests

  1. Click Details icon on a pending request
  2. Review request details:
  3. Who is requesting
  4. What access they need
  5. Why (justification)
  6. When requested
  7. Click Approve or Reject
  8. Optionally provide comment
  9. Access is granted/denied immediately

Security recommendations:

  • Review justification before approving
  • Verify requester's identity through separate channel for sensitive access
  • Document approval decision in comment field
  • Set up approval workflows requiring multiple approvers for high-privilege access
  • Monitor for unusual request patterns (bulk requests, repeated rejections)

Request Templates

Location: Access Requests > Request Templates

Purpose: Define pre-configured access request templates that users can self-service request.

What you can do

  • View templates: See all configured access request templates
  • Create templates: Define new requestable access patterns
  • Edit templates: Update template configuration
  • Delete templates: Remove unused templates

Template Types

RBAC Group Access:

  • User requests membership in a specific group
  • Upon approval, user is added to the group
  • User inherits all group roles and permissions
  • Use case: "Request Developer Access" → adds user to "developers" group

Resource Access (UMRS):

  • User requests a specific UMRS role on a resource
  • Upon approval, user gets role grant on that resource
  • Supports resource-level access control
  • Use case: "Request Project Alpha Access" → grants "viewer" role on "project-alpha" resource

RBAC Group Extension Request:

  • User requests to extend their membership in a group they're already in
  • Prevents automatic removal upon expiration
  • Use case: Contractor extends "external-developers" membership for another quarter

Resource Extension Request (UMRS):

  • User requests to extend their UMRS role grant
  • Extends expiration date on existing grant
  • Use case: Project team member extends access beyond initial timeframe

Template Table Columns

  • Access Request Name: Template display name
  • Application: Associated client application (optional)
  • Target Resource: What access this grants (group name or UMRS role)
  • Settings: Edit template configuration
  • Delete: Remove template

Creating a Template

  1. Click + ADD NEW dropdown
  2. Select template type:
  3. RBAC Group Access: Group membership request
  4. Resource Access: UMRS role grant request
  5. RBAC Group Extension Request: Extend group membership
  6. Resource Extension Request: Extend UMRS grant
  7. Configure template (see Request Template Configuration)
  8. Click Save

Security recommendations:

  • Create templates only for access that should be self-serviceable
  • Require approval for all sensitive access (don't use auto-approval)
  • Set appropriate expiration times for approval windows
  • Use clear, descriptive template names
  • Document approval workflow in template description

User-Managed Roles (UMRS)

Location: Access Requests > User-Managed Roles

Purpose: Define roles that designated managers can grant without being full admins.

What is UMRS?

User-Managed Role System (UMRS) enables delegated administration:

  • Project leads can grant project-specific access
  • Team managers can control team resource access
  • Non-admins can manage access to resources they own
  • Reduces admin bottleneck for routine access grants

What you can do

  • View UMRS roles: See all user-managed roles
  • Create UMRS roles: Define new delegated roles
  • Edit UMRS roles: Update role configuration
  • Delete UMRS roles: Remove unused roles
  • Configure managers: Designate who can grant this role

UMRS Role Table Columns

  • Name: Role identifier
  • Description: Role purpose
  • Resource Server: API/resource this role applies to
  • Settings: Edit role configuration
  • Delete: Remove role

Creating a UMRS Role

  1. Click + ADD User Role
  2. Configure role:
  3. Name*: Unique role identifier
  4. Description*: What this role grants access to
  5. Managers Group*: Group whose members can grant this role
  6. Resource Server*: API or resource this role controls
  7. Allow Grant Extension Requests: Users can request to extend their grants
  8. Click Save

Example configuration:

Name: project-alpha-viewer
Description: View-only access to Project Alpha resources
Managers Group: project-alpha-leads
Resource Server: Project Management API
Allow Grant Extension Requests: Yes

Result: Members of "project-alpha-leads" group can grant "project-alpha-viewer" role to users without needing full admin privileges.

UMRS vs. Regular Roles

Feature Regular Roles UMRS Roles
Who can grant Admins only Designated managers
Scope Tenant-wide Resource-specific
Expiration Permanent Can be time-limited
Extension N/A Can allow requests
Delegation No Yes

Use cases:

  1. Project-based access: Project managers control project resource access
  2. Team resources: Team leads manage team-specific tools
  3. Departmental apps: Department heads grant access to department resources
  4. Customer resources: Account managers control customer data access

Security benefits:

  • Reduces admin workload for routine access grants
  • Empowers domain experts to manage their resources
  • Maintains audit trail of who granted what
  • Enables fine-grained, resource-level access control

Access Grants

Location: Access Requests > Access Grants

Purpose: View and manage all UMRS role grants (user-to-role and group-to-role assignments for UMRS roles).

Dashboard structure: Two tabs:

  1. User Grants: Individual user assignments to UMRS roles
  2. Group Grants: Group assignments to UMRS roles

User Grants Tab

What you can see:

  • Resource Server: API or resource
  • Resource: Specific resource instance (e.g., "project-123")
  • Role: UMRS role granted
  • User: User who has this grant
  • Expires: Expiration date (or "never")
  • Settings: Edit expiration
  • Delete: Revoke grant

What you can do:

  • Add user to role: Click + ADD User to Role
  • Select UMRS role
  • Select user
  • Set resource ID
  • Set expiration date (optional)
  • User immediately gets access
  • Edit expiration: Click Settings icon
  • Update expiration date
  • Extend or shorten access duration
  • Revoke grant: Click Delete icon
  • Remove user's access immediately
  • User loses role-based permissions

Group Grants Tab

What you can see:

  • Resource Server: API or resource
  • Resource: Specific resource instance
  • Role: UMRS role granted to group
  • Group: Group that has this grant
  • Expires: Expiration date (or "never")
  • Settings: Edit expiration
  • Delete: Revoke grant

What you can do:

  • Add group to role: Click + ADD Group to Role
  • Select UMRS role
  • Select group
  • Set resource ID
  • Set expiration date (optional)
  • All group members immediately get access
  • Edit expiration: Update group grant expiration
  • Revoke grant: Remove group's access

User Grants vs. Group Grants

Use user grants when:

  • Individual user needs exceptional access
  • One-off access requirement
  • Temporary access for specific person

Use group grants when:

  • Multiple users need same access
  • Access aligns with organizational structure (team, project)
  • Recurring pattern (many people will need this over time)

Best practice: Prefer group grants over individual user grants for maintainability and scalability.

Security recommendations:

  • Set expiration dates for all grants (avoid permanent grants)
  • Review grants quarterly and remove unnecessary access
  • Monitor for grants that never expire
  • Use shortest reasonable expiration period
  • Require re-approval for extensions

Group Invitations

Location: Access Requests > Group Invitations

Purpose: Send email invitations to users to join groups, with optional confirmation workflow.

What you can do

  • View invitations: See all group invitations (pending, accepted, expired)
  • Create invitations: Invite users to join groups via email
  • Monitor status: Track which invitations are pending, accepted, or expired
  • Delete invitations: Cancel pending invitations

Invitation Table Columns

  • Status: pending, accepted, expired
  • Group: Target group user is invited to join
  • Email: Invitee's email address
  • Created By: Who sent the invitation
  • Created At: When invitation was sent
  • Updated At: Last status change
  • Expires (minutes): Time until invitation expires
  • Group Access Expiration Date: When group membership will expire (if set)
  • Delete: Cancel invitation

Creating a Group Invitation

  1. Click + ADD INVITATION
  2. Fill in invitation details:
  3. Group*: Select group to invite user to
  4. User Email*: Email address of invitee (can autocomplete existing users or enter new email)
  5. Identity Issuer*: Which IdP the user will authenticate with
  6. Application URL*: Redirect URL after accepting invitation
  7. Expiration (minutes): How long invitation remains valid
  8. Require Invitation Confirmation: Whether user must click link to accept
  9. Invitation Template*: Email template for invitation message
  10. Confirmation Template: HTML page shown after accepting (if confirmation required)
  11. Set membership expiration date: Optional expiration for group membership
  12. Click Save
  13. Invitation email is sent immediately

Invitation Workflow

Without confirmation:

  1. Invitation is created
  2. Email is sent to user
  3. User is automatically added to group
  4. User can access group resources immediately

With confirmation required:

  1. Invitation is created
  2. Email is sent with confirmation link
  3. User clicks link and sees confirmation page
  4. User is added to group after confirmation
  5. User can access group resources

Expiration behavior:

  • Invitation expires after specified time
  • Expired invitations cannot be accepted
  • Must create new invitation if expired

Membership expiration:

  • If set, user's group membership expires on specified date
  • User is automatically removed from group at expiration
  • User can request extension if group allows extension requests

Use cases:

  1. Onboarding: Invite new employees to "employees" group
  2. Project teams: Invite contractors to "project-x-contractors" group with expiration
  3. Temporary access: Invite auditors to "auditors" group for limited time
  4. Self-service: Allow users to accept invitations without admin intervention

Security recommendations:

  • Set reasonable expiration times (1-7 days for invitations)
  • Use confirmation for sensitive group invitations
  • Set membership expiration for temporary access
  • Monitor for expired invitations and clean up
  • Require identity issuer for non-existing users to prevent wrong IdP selection

SSH Secrets

Location: Access Requests > SSH Secrets

Purpose: Generate SSH access credentials for users to access remote servers or command-line interfaces.

Availability: Requires auth.admin.usersshsecret scope (elevated permission).

What you can do

  • Create SSH access: Generate SSH key pair and configuration for a user
  • Download credentials: Receive JSON file with SSH private key, public key, and connection details

Creating SSH Access

  1. Navigate to SSH Secrets dashboard
  2. Fill in the form:
  3. User Email*: Search and select the user who needs SSH access
    • Autocomplete searches across all tenant users
    • Shows email, name, and identity issuer
  4. SSH Server*: Hostname or IP of the SSH server
    • Example: ssh.example.com, 10.0.1.50
  5. SSH Username*: Username for SSH login
    • Example: ubuntu, ec2-user, user's system username
  6. Click Create SSH Secret
  7. JSON file downloads automatically with credentials

Downloaded Credentials Format

{
  "userId": 123,
  "userEmail": "user@example.com",
  "sshServer": "ssh.example.com",
  "sshUsername": "ubuntu",
  "publicKey": "ssh-rsa AAAAB3NzaC1yc2EA...",
  "privateKey": "-----BEGIN OPENSSH PRIVATE KEY-----\n...",
  "sshConfig": "Host ssh.example.com\n  User ubuntu\n  IdentityFile ~/.ssh/auth_rsa"
}

Installing SSH Credentials (User Instructions)

For users receiving SSH access:

  1. Save the privateKey to ~/.ssh/auth_rsa
  2. Set permissions: chmod 600 ~/.ssh/auth_rsa
  3. Add public key to authorized_keys on server (admin task) or use provided config
  4. Connect: ssh -i ~/.ssh/auth_rsa ubuntu@ssh.example.com

Server-side setup (requires server admin):

# Add user's public key to authorized_keys
echo "ssh-rsa AAAAB3NzaC1yc2EA..." >> /home/ubuntu/.ssh/authorized_keys
chmod 600 /home/ubuntu/.ssh/authorized_keys

Security warnings:

⚠️ Critical: The downloaded private key cannot be retrieved again. If lost, generate new credentials.

⚠️ Secret material: Treat downloaded JSON as highly sensitive (contains private key)

⚠️ One-time download: Securely transmit to user or have user generate in self-service portal

Security recommendations:

  • Rotate SSH keys regularly (every 90-180 days)
  • Audit SSH key creation (elevated privilege operation)
  • Secure private key storage: Use password-protected key files or SSH agent
  • Revoke unused keys: Delete from server's authorized_keys when no longer needed
  • Set key expiration: Implement key expiration policies on SSH servers
  • Monitor SSH access logs: Track who accesses what via SSH
  • Use separate keys per server: Don't reuse keys across environments
  • Require strong passphrases: If possible, generate password-protected keys

Batch Invite

Location: Access Requests > Batch Invite

Purpose: Bulk invite multiple users to a group in a single operation, ideal for onboarding teams or classes of users.

What you can do

  • View batch operations: See all batch invite jobs with status tracking
  • Create batch invites: Invite many users at once with a single email template
  • Monitor progress: Track success/failure/pending counts
  • View details: Examine individual invitation results
  • Copy batch jobs: Reuse configuration for similar operations

Batch Operations Table Columns

  • Requested By User: Who initiated the batch operation
  • Invitation Group: Target group for invitations
  • Success: Count of successful invitations (clickable for details)
  • Failure: Count of failed invitations (clickable for details)
  • Pending: Count of pending invitations (clickable for details)
  • Total Requests: Total number of users in batch
  • Status: Overall batch job status (processing, completed, failed)
  • Description: Batch operation description
  • Created At: When batch was initiated
  • Details: View full batch details
  • Copy: Clone configuration for similar batch operation

Creating a Batch Invite

  1. Click + BATCH INVITE
  2. Fill in batch configuration:
  3. Group*: Select target group (autocomplete search)
  4. Users*: JSON array of email addresses
    • Format: ["user1@example.com", "user2@example.com", "user3@example.com"]
    • Monaco code editor with syntax validation
  5. Redirect URL*: Where users land after accepting invitation
  6. Identity Issuer*: IdP users will authenticate with
  7. Description*: Purpose of this batch operation
  8. Email Template*: Template for invitation emails
  9. Require Confirmation: Whether users must click link to accept
  10. Expiration (minutes): How long invitations remain valid (if confirmation required)
  11. Confirmation Template: HTML page for invitation acceptance (if confirmation required)
  12. Click Save
  13. Batch processing begins asynchronously

Batch Processing

Lifecycle:

  1. Submitted: Batch job created and queued
  2. Processing: System sends invitations sequentially
  3. Completed: All invitations processed (may include some failures)
  4. Failed: Batch job encountered fatal error

Monitoring progress:

  • Click Success/Failure/Pending counts to see specific invitations
  • Click Details to view full batch configuration and all results
  • Copy button allows repeating similar batch operations

Handling failures:

  • Review failure details (invalid email, user already in group, quota exceeded)
  • Fix issues and create new batch for failed entries
  • Check logs for systematic issues

Batch Invite JSON Format

[
  "alice@example.com",
  "bob@example.com",
  "charlie@example.com",
  "diana@example.com"
]

Validation: JSON must be an array of strings (email addresses).

Use cases:

  1. Class enrollment: Invite 50 students to "course-2025-spring" group
  2. Department onboarding: Add 20 new hires to "engineering" group
  3. Event access: Grant 100 attendees access to "conference-2025" group
  4. Partner onboarding: Invite partner organization users to collaboration group

Best practices:

  • Test with small batch first (2-3 users) before large operations
  • Use meaningful descriptions (e.g., "Q1 2025 Intern Onboarding")
  • Monitor batch progress for failures
  • Keep batch sizes reasonable (< 1000 users per batch)
  • Have email addresses validated before batching
  • Use confirmation for new users, skip for existing users

Security recommendations:

  • Verify email list before submission (avoid typos)
  • Ensure all recipients should actually get this access
  • Use group expiration for temporary batch access
  • Audit batch operations regularly (powerful capability)
  • Limit who can create batch invites (consider requiring approval)

Request Template Configuration

RBAC Group Access Template

Purpose: Allow users to request membership in a specific group.

Configuration Fields

  • Requested Group*
  • The group users will be added to upon approval
  • Autocomplete search with filtering
  • Shows group name and description

  • Create Group button: Quick-create group if it doesn't exist

  • Request Template Display Name*

  • User-facing name for this access request option
  • Example: "Request Developer Access", "QA Environment Access"

  • Should clearly describe what access is granted

  • Inviter/Approver Group*

  • Group whose members can approve requests
  • Members of this group receive approval notifications
  • Can invite others directly (bypass request workflow)

  • Create Group button: Quick-create approver group if needed

  • Accept/Approve Within*

  • Deadline for approval
  • After this time, request expires and cannot be approved
  • Units: days or minutes
  • Example: 7 days, 1440 minutes (1 day)

  • Security note: Shorter windows reduce exposure of pending requests

  • Invitation Email Template*

  • Email template used when sending invitation/approval emails
  • Select from configured email templates

  • Should include:

    • What access is being granted
    • How to accept or request
    • Expiration information

  • Client Application

  • Associate this template with a specific application (optional)
  • Helps users understand what app they're getting access to

  • Used for audit and reporting

  • Description

  • Internal description of template purpose
  • Not shown to requesters
  • Use case: Document approval requirements, escalation paths

Example template:

Template Display Name: Request Production Database Access
Requested Group: production-db-users
Approver Group: database-administrators
Accept/Approve Within: 3 days
Email Template: Standard Access Request
Client Application: Production DB Management Portal
Description: Grants read-only access to production databases. Requires DBA approval. Must have completed security training.

Resource Access Template (UMRS)

Purpose: Allow users to request UMRS role grants on specific resources.

Configuration Fields

Similar to RBAC template, plus:

  • UMRS Role*
  • Select from configured UMRS roles
  • Determines what permissions are granted
  • Resource Scope
  • Whether user can specify resource ID
  • Or template is for a specific pre-defined resource

Use case: "Request Project Access" where users specify which project (resource ID) they need access to.

Extension Request Templates

Purpose: Allow users to request extension of existing access beyond original expiration date.

RBAC Group Extension:

  • User is already in group with expiration
  • Requests to extend membership
  • Approver can grant extension

Resource Extension (UMRS):

  • User has UMRS role grant with expiration
  • Requests to extend grant
  • Manager can approve extension

Configuration: Similar to access templates, but applied to existing grants rather than creating new ones.

Security benefit: Forces periodic re-approval of access, ensuring access is still appropriate.

UMRS Role Configuration

Creating a UMRS Role

Detailed explanation of each field in UMRS role creation dialog:

Name*

  • Unique identifier for the role
  • Format: Use descriptive, resource-scoped names
  • Examples:
  • project-alpha-admin
  • api-orders-viewer
  • resource-editor
  • Naming convention: <resource>-<privilege-level>

Description*

  • Human-readable explanation of what this role grants
  • Shown to users when requesting access
  • Examples:
  • "Full administrative access to Project Alpha resources"
  • "View-only access to Order Management API"
  • "Edit permissions for shared resources"

Managers Group*

  • Group whose members can grant this role
  • Critical choice: This delegates admin power to non-admins
  • Autocomplete search with filtering
  • Security note: Only assign manager rights to trusted groups

Example scenario:

UMRS Role: project-beta-contributor
Managers Group: project-beta-leads
Result: Members of "project-beta-leads" can grant "project-beta-contributor" role

Resource Server*

  • The API or resource system this role controls access to
  • Select from configured resource servers (APIs)
  • Determines what permissions this role can grant
  • Example: "Project Management API", "Document Storage API"

Allow Grant Extension Requests

  • Toggle to enable users to request access extensions
  • When enabled, users with this role can request to extend their grant before expiration
  • Managers receive extension requests for approval
  • Use case: Project-based access where timelines may extend

Security consideration: Extensions should also require approval; don't allow automatic extensions.

Security Best Practices

Access Request Security

  1. Require approval for sensitive access
  2. Don't use auto-approval for privileged groups
  3. Require justification in requests
  4. Implement multiple-approver workflows for critical access

  5. Monitor approval patterns (who approves what)

  6. Set appropriate expiration windows

  7. Short approval windows (3-7 days) for routine access
  8. Longer windows (30 days) for complex approvals requiring research
  9. Expire requests that aren't approved promptly

  10. Clean up expired requests regularly

  11. Audit request activity

  12. Review approval patterns for abuse
  13. Monitor for unusual request volumes
  14. Track approver actions

  15. Alert on rejected requests (may indicate attack or confusion)

  16. Validate requesters

  17. Ensure requester identity is verified
  18. Check for legitimate business need
  19. Verify requester is using correct IdP
  20. Watch for social engineering attempts

UMRS Security

  1. Carefully choose managers
  2. Manager groups wield delegated admin power
  3. Only grant to trusted, trained individuals
  4. Review manager group membership quarterly

  5. Require security awareness training for managers

  6. Scope UMRS roles narrowly

  7. Create resource-specific roles, not tenant-wide
  8. Limit permissions in UMRS roles to minimum required
  9. Don't create overly broad UMRS roles

  10. Regular roles for broad access; UMRS for specific resources

  11. Enforce time limits

  12. Always set expiration dates on UMRS grants
  13. Require re-approval for extensions
  14. Shorter expirations for higher-risk resources (30-90 days)

  15. Longer expirations for stable team access (180-365 days)

  16. Monitor delegation

  17. Audit who is granting what access
  18. Watch for managers granting to themselves
  19. Alert on unusual grant patterns

  20. Review grant extensions for necessity

  21. Separate privileges

  22. Don't make the same group both target and manager
  23. Separate "can grant" from "has access"
  24. Prevent circular delegation patterns

Group Invitation Security

  1. Verify email addresses
  2. Double-check email lists before batch operations
  3. Prevent typos that send invitations to wrong people
  4. Use domain validation (e.g., only @company.com)

  5. Monitor for suspicious external domains

  6. Use confirmation for new users

  7. Require invitation acceptance click
  8. Prevents accidental group additions
  9. Gives users visibility into what access they're getting

  10. Creates audit trail of user consent

  11. Set membership expiration

  12. Use for contractors, consultants, temporary staff
  13. Review and re-approve before extension
  14. Automatic cleanup when period ends

  15. Reduces orphaned access

  16. Monitor invitation abuse

  17. Track who is sending invitations
  18. Alert on large batch operations
  19. Review expired invitations (may indicate incorrect emails)
  20. Watch for invitation spam patterns

SSH Access Security

  1. Treat as highly privileged
  2. SSH access is powerful (terminal access)
  3. Require elevated admin scope for creation
  4. Limit who can generate SSH credentials

  5. Audit all SSH key generations

  6. Secure private keys

  7. Transmitted once (in download)
  8. User must protect private key
  9. Consider password-protecting keys

  10. Use SSH agent for key management

  11. Rotate keys

  12. Regular rotation schedule (90-180 days)
  13. Immediate rotation on compromise
  14. Remove old keys from servers

  15. Maintain key inventory

  16. Monitor SSH usage

  17. Log SSH connections on servers
  18. Alert on unusual access patterns
  19. Correlate with user access grants

  20. Investigate unauthorized access attempts

  21. Server-side controls

  22. Implement server-side key expiration
  23. Use SSH certificate authorities for short-lived certs
  24. Restrict SSH access by IP/network
  25. Enable 2FA for SSH (if supported)

Operational Security

  1. Document workflows
  2. Clear procedures for access requests
  3. Approval SLAs (how quickly to respond)
  4. Escalation paths for urgent requests

  5. Training materials for approvers

  6. Regular reviews

  7. Weekly: Review pending requests (avoid backlog)
  8. Monthly: Audit approved access grants
  9. Quarterly: Review template configurations

  10. Annually: Comprehensive access audit

  11. Automate where safe

  12. Low-risk access can be auto-approved
  13. High-risk access requires human approval
  14. Use approval rules based on group/resource sensitivity

  15. Monitor automated approvals for abuse

  16. Maintain audit trail

  17. All requests logged with timestamps
  18. Approver identity recorded
  19. Rejection reasons documented
  20. Support forensic investigation

Additional Resources

  • Users and Groups Management Guide: packages/auth/docs/guides/users-groups-admin-guide.md
  • SSO Integration Guide: packages/auth/docs/guides/sso-integration-guide.md
  • Tenant Administrator Guide: packages/auth/docs/guides/tenant-admin-guide.md
  • Super Admin Access Reference: packages/auth/docs/authorization/super-admin-access.md
  • Admin Roles Overview: packages/auth/docs/authorization/admin-roles.md

Getting Help

For assistance with access requests and delegated administration:

  1. Check audit logs for request and approval history
  2. Review request templates to ensure they're configured correctly
  3. Test workflows in non-production before deploying
  4. Monitor batch operations for failures and investigate
  5. Contact your admin team for policy questions or approval escalations

Document version: 1.0
Last updated: 2025-12-12
Target audience: Tenant Administrators, UMRS Managers
Scope: Self-service access management and delegated administration