Chapter 34 — Identity and access management: integration | Engineering Identity and access management

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 34 — Identity and access management: integration

Lesson map

Lesson 34 published. Map, example, EX100.

flowchart TD
  N0["Learning outcomes"]
  N1["34.1 Logging integration"]
  N2["34.2 HR and service desk integration"]
  N3["34.3 Security monitoring"]
  N4["34.4 Teams and handover"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX100"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["34.1 Logging integration"]
  N2["34.2 HR and service desk integration"]
  N3["34.3 Security monitoring"]
  N4["34.4 Teams and handover"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX100"]

[Learning outcomes]
    |
    v
[34.1 Logging integration]
    |
    v
[34.2 HR and service desk integration]
    |
    v
[34.3 Security monitoring]
    |
    v
[34.4 Teams and handover]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX100]

Learning outcomes

You will (1) integrate identity with logging, HR, the service desk and security monitoring; (2) agree team responsibilities; (3) hand over monitoring.

34.1 Logging integration

The provider's sign-in and audit logs must reach the council's central log store with consistent fields and UTC timestamps. Sana maps provider fields to the schema from chapter 13 and tests that synthetic events arrive complete and promptly. She checks that tokens and passwords never appear in logs, and that administrator actions are recorded in a store administrators cannot alter. Gaps found in testing, such as missing device information for some sign-ins, are fixed before the logs are relied on for monitoring or investigations.

34.2 HR and service desk integration

HR is the source of truth for joiners, movers and leavers, so the feed's reliability is critical. Sana agrees with HR when changes become effective, how errors are corrected and who is alerted when the feed fails. The service desk tool is integrated so agents can see an identity's status, recent sign-in failures and authenticator registrations without needing administrator rights. Resets and recoveries are logged as tickets linked to the identity, so patterns of repeated recovery, a possible sign of abuse, become visible.

34.3 Security monitoring

The council's security monitoring team receives alerts for high-risk identity events: sign-ins combining a new device and unusual location, repeated failed second factors, use of emergency accounts, administrator role activation outside change windows and leaver connector failures. Sana writes a runbook for each alert type with the context to check and the actions to take. Following the base-rate reasoning from chapter 7, alerts combine several signals, so analysts see fewer, more meaningful alerts rather than a flood they learn to ignore.

34.4 Teams and handover

Several teams share identity responsibilities: the identity team runs the provider, HR owns the feed, application owners approve access, the service desk handles resets and security monitoring handles alerts. Sana writes a responsibility table and reviews it with each team, so tasks do not fall between them. She runs handover sessions and pairs with identity team members on real changes, because the real test of integration is whether everything keeps working after her project ends and she is no longer there to answer questions.

Worked example

Five identity alert types with runbooks are handed to security monitoring; the responsibility table assigns each of twelve identity tasks to one owning team.

Synthetic case. Teams, alerts and tasks are synthetic.

Errors and limits

Integrating alerts without runbooks leaves analysts unsure what to check or do.

Exercises

EX100 — Repeated recovery signal. Why link resets to identities as tickets? Rubric: 3 = patterns of repeated recovery become visible as possible abuse;; 2 = patterns;; 1 = billing;; 0 = none.
EX101 — Alert examples. Name two identity alert types sent to monitoring. Rubric: 3 = new device plus unusual location, failed second factors, emergency account use, admin activation, connector failure (two);; 2 = one;; 1 = vague;; 0 = none.
EX102 — Integration test. What is the real test of integration? Rubric: 3 = everything keeps working after Sana leaves;; 2 = handover;; 1 = go-live;; 0 = none.

Synthesis

Clean log integration, a reliable HR feed, desk visibility, meaningful alerts and clear ownership make identity part of everyday operations.

Continue studying — chapter 34 of 50

← Chapter 33 (draft) · Course chapter index · Chapter 35 (draft) →