The planned scenario
Identity reviews span more than a login screen. Cloud Identity Lab places helpdesk requests, an application catalog, audit views, and token metadata alongside private identity relationships and access review records. It gives a team a setting for discussing who may grant access, who may recover an account, and what evidence those decisions should leave.
Separate visible application access from the role and group relationships behind it. An exercise can follow an account recovery request or an application consent review through the available records, with explicit questions about approval and accountability.
Public surfaces
These reference routes describe possible entry points in the scenario model. They are not live customer services or a guarantee of the routes in a particular product release. Use your configured exercise inventory as the authoritative scope.
| Route | Surface | Context |
|---|---|---|
/ | helpdesk-portal | Helpdesk and account recovery workflow facade. |
/apps | app-catalog | Enterprise app catalog and consent review surface. |
/audit | audit-viewer | Audit event viewer facade. |
/tokens | token-service | Token and session metadata facade for lab review. |
Private systems
These service names and segments describe the internal context of Cloud Identity Lab. They help define exercise boundaries and interpret the generated records.
identity-graphPrivate user, group, role, and app relationship data. Catalog segment: private application.
access-reviewPrivileged access review workflow simulation. Catalog segment: private application.
sso-config-storeSSO and conditional access configuration store. Catalog segment: private data.
breakglass-workflowBreak glass account workflow representation. Catalog segment: private application.
Configure your exercise
Choose a question for the assignment and define the evidence participants should collect.
- Which user, group, role, and application relationships support a particular access decision?
- What should a helpdesk operator see or change during account recovery, and what requires separate approval?
- How would a reviewer distinguish ordinary access, application consent, and emergency access in the available audit context?
What to hand in
Document the identity relationship under review, the expected approval boundary, and the artifacts that support or fail to support it. Keep the proposed control separate from behavior actually observed in the range.
Records and evidence
Users, groups, application consents, access reviews, conditional access records, and service principals support relationship analysis without real employee accounts. Keep conclusions tied to those synthetic records and the identity and access boundaries configured for the exercise.
usersgroupsapp-consentsaccess-reviewsconditional-accessservice-principals
Preserve the scenario and product version, the record or observation, and its source with each finding. Distinguish what a participant observed from what the reviewer inferred. Use synthetic data and your defined evidence-retention rules.
Public self-service at launch
Managed Verse is planned for 1 January 2027. Users will create an account, choose a scenario and configure their own authorized exercise boundaries. Vulnverse will host and operate the platform and cloud; users will not need to provision or maintain an exercise cloud.
Managed Verse is planned to replace all previous services. All new inquiries are paused during the transition. Read Managed Verse →.