Identity and Access Management TryHackMe Writeup

Q: What is the difference between performing a principle and applying it?

Performing is the mechanism running: a credential validated, a policy evaluated, an event recorded. Applying is the result taking effect in the running system: the identity established is the one used, the decision gates the action, the record supports attribution.

Q: Why is a replay attack possible if the credential is genuine?

Because a valid credential is not a fresh one. Nothing is forged or decrypted; a credential is observed and sent again and accepted because it is valid. Binding it to the exchange with a nonce, a bounded timestamp or a challenge makes a copied credential unusable.

Q: Does single sign-on make identity management safer or riskier?

Both. Centralising authentication makes the mechanism more likely to be correct, while making each receiving service's separate decision to apply the assertion more consequential, so a failure to apply one grows with the estate.

Identity and access management is built on three principles, and every one of them can be performed without being applied. A credential can be presented and accepted while the identity it established never reaches the decision. A policy can be evaluated while the decision never gates the action. An event can be recorded while the record never identifies anybody. In each case the mechanism ran, something happened, and the property the principle exists to guarantee was never established.

This is the companion to today's field note on a library that accepted a privilege-dropping argument and did not drop the privileges. That piece is about one API and three advisories. This one is about the same gap stated as a model, because the model is what makes it findable in an environment rather than in a diff.

The TryHackMe room that prompted it is an introduction, and I am writing about it as a model rather than as a walkthrough. No flags, no answers, no working attack chain. What follows is the structure the room teaches, the distinction it makes between performing a principle and satisfying it, and the checks that tell the two apart.

The three principles of identity and access management, identification, authorisation and accountability, each shown in two columns: the mechanism that gets performed, and the effect that must be applied, with the replay attack as the worked case where a valid credential was accepted and freshness was never applied — Three principles, and every one of them has a mechanism that can run without taking effect.

01 · Scope and authorisation

This is an authorised companion to a public introductory TryHackMe room on identity and access management. Everything here is written against the room's published learning objectives, the NIST definition of IAM the room cites, and standard reference material on authentication, authorisation and accountability. I have deliberately excluded flags, quiz answers and any complete attack procedure. Where the room teaches an attack class, I describe the mechanism and the control it defeats rather than how to carry it out.

If you are working through the room, read this alongside it rather than instead of it. The room supplies the terminology and the exercises; this supplies a model for why the distinctions it is drawing matter once you leave the exercise.

02 · Learning objectives

State the three principles IAM is built on and what each one is for.
Separate the mechanism that performs a principle from the effect that satisfies it.
Explain Identity Management and Identity and Access Management as different scopes rather than competing terms.
Describe what a replay attack exploits, and why the credential in it is not the weak part.
Explain what Single Sign-On changes about where identity decisions are made, and what it makes worse when one of them is performed without being applied.
Apply a three-question check to any identity flow you are reviewing.

03 · Prerequisites and the loop

The room assumes no prior identity background, and the only prerequisite for the model here is a willingness to hold two words apart. The habit I would build is a four-step loop applied to every identity question you meet: state the principle being invoked, name the mechanism that performs it, identify the effect that would satisfy it, then ask what evidence exists that the effect occurred. The fourth step is the one that gets skipped, and it is the only one that distinguishes the two states.

The vocabulary worth having before you start is small. Identification is establishing which subject is making a request. Authorisation is deciding what that subject may do. Accountability is being able to attribute what was done to a subject afterwards. The room presents these as the principles IAM rests on, and the model in the next section treats each one as something a mechanism attempts and an effect completes.

04 · The model: three principles, each performed by something

Every principle in this subject is invoked by a mechanism, and the mechanism is what people build, test and review. That is the source of the whole problem. The mechanism is visible, it is in the diagram, and it produces an output. The principle it exists to establish is one layer further down, at the point where the output changes what the system does.

So I find it useful to read each principle twice, once as a mechanism and once as an effect. Identity gets established by something and applied when that identity is the one every subsequent decision is made against. Authorisation gets decided by something and applied when the decision actually gates the action. Accountability gets recorded by something and applied when the record supports attribution without ambiguity.

Two consequences follow, and they are the reason the model is worth carrying around. The first is that a mechanism can be present, correct and running while its principle is unsatisfied, because presence is a property of the build and satisfaction is a property of the running system. The second is that the failure is silent by construction, since the mechanism produces its output either way and nothing in the output distinguishes a decision that gated from a decision that did not.

05 · Principle one: identification, and the identity that must survive

Identification is the least contested of the three and the one most often performed without being applied, because establishing an identity and using it happen in different places.

The mechanism establishes who is asking. It validates a credential, or resolves a session, or accepts an identity from something upstream that is trusted to have done one of those. All of that is real work and it produces a real result. The question the principle actually cares about is different: is the identity that was established the identity that the later decision is made against, at every layer, on every path, in every service the request touches.

Where this fails in practice, the pattern is consistent. The identity is established at an edge and travels inward as an assertion, and the layers behind the edge have to decide independently whether to believe it. A layer that believes it correctly is doing the right thing; a layer that prepares to believe it and then never consults it has performed identification and not applied it. The mechanism that resolves identity ran, the result was available, and the decision downstream was made against something weaker.

The check is to follow the identity rather than the credential. Ask where the value is set, where it is read, and what the decision looks like at each point where it could have been used. Any place where the decision could have consulted the established identity and did not is a place where the principle was performed.

06 · Principle two: authorisation, and the decision that must gate

Authorisation fails in the same way and with higher consequences, because a decision that does not gate is indistinguishable from no decision at all.

The mechanism evaluates a policy and returns an answer. That evaluation is the part that gets tested, and it is usually correct, because policy evaluation is well-understood and easy to unit test. The principle cares about whether the answer actually stands between the request and the effect. A decision rendered and not enforced is a log line, not a control.

Two failure shapes recur, and neither is visible in the policy. The first is coverage: the enforcement point exists on the paths where authorisation was considered and is absent on the paths where it was not, which is a question about where the check was installed rather than what it does. The second is fidelity: the enforcement consults the decision using the wrong description of the action. A middleware that maps a set of methods onto a coarser set of permissions can approve an operation it was never asked about, because the mapping collapses distinctions the policy depends on. In both cases the evaluation is correct and the authorisation is not applied, because what was evaluated and what was permitted are not the same question.

The check follows the same shape as the last one. For each operation, ask which enforcement point the request passed through, what description of the action that point used, and whether the policy was written against the same description. Where those three disagree, the authorisation was performed and not applied.

07 · Principle three: accountability, and the record that must attribute

Accountability is the principle most often assumed to be satisfied by infrastructure, and the one where the assumption is least safe.

The mechanism records an event. Logs exist, they are shipped, they are retained, and all of that is genuine operational work. The principle asks whether the record supports attribution, which is a stronger requirement: given a record of an action, can you name the subject, unambiguously, and connect that subject to the action in a way that survives someone disputing it.

Two failures recur here as well. The record can be attributable to the wrong subject, which happens whenever the identity used in the record is the one presented rather than the one established, so a request that carried a forged or replayed assertion produces a log line naming whoever the assertion claimed to be. And the record can be absent in exactly the cases that matter, because the events worth attributing are often the ones that do not follow the normal path, and instrumentation tends to live on the normal path.

The check for this principle is the sharpest of the three, because it is answerable directly: take one record of one action and try to fail it. Ask who did this, how you know, and what would have to be true for the answer to be wrong. If the record only supports the first question, the mechanism recorded and the principle was not applied.

08 · The worked case: replay, where validity stood in for novelty

The room's attack section is the best illustration of the model, because the credential in a replay attack is genuine and nothing about it is broken.

In a replay, an attacker observes a credential in transit and sends it again. Nothing is forged, nothing is altered, and nothing is decrypted. The service receives a credential it issued, presented by someone it did not issue it to, and accepts it, because the credential is valid. Identification was performed correctly and completely: a real credential was presented and accepted by the mechanism that checks credentials.

What was never applied is freshness. The principle in play is that a credential should be usable by the party it was issued to, in the exchange it was issued for, and the only way to establish that is to bind the credential to something that does not survive being copied. A nonce that the server expects once, a timestamp inside a tolerance window, a sequence number, a challenge the client must incorporate. Each of those turns the credential from something that is valid into something that is valid here and now, and without one of them the exchange has no way to tell a first use from a second.

That is why this case belongs in the model rather than beside it. The failure is not in the credential check, which worked. It is that acceptance was treated as the effect, when the effect the service needed was novelty, and novelty is a property of the exchange rather than a property of the credential. The mechanism ran, the credential was valid, and the property that mattered was never established, and nothing in the exchange reported the difference.

The generalisable statement is the one worth carrying out of the room: wherever a credential is accepted, ask what makes this presentation of it different from the previous one. If the answer is nothing, the check is performing identification and the exchange is not applying it.

09 · Single sign-on, and why propagation raises the stakes

Single sign-on is where the model stops being academic, because it deliberately moves identity decisions to one place and then propagates the result to many.

The trade the room describes is real and worth stating plainly. Centralising authentication means one place to get it right, one place to enforce a strong factor, one place to revoke, and one place to audit. It also means everything downstream depends on the assertion that arrives from that place, and the assertion is now the entire basis for identification at every service that receives it. The centre can be perfect and the system can still be wrong, because the question of whether each receiving service applied the identity it was given is asked separately at every service.

So SSO amplifies both directions of the model. It makes the mechanism more likely to be correct, since there is only one of it and it is worth investing in. It makes a failure to apply the result more consequential, because the number of places where a decision can be made against the wrong identity grows with the number of services, and each of them is individually making a reasonable-looking choice about whether to trust what arrived.

The check is the one from the identification section, applied per service: where is the identity set for this service, where is it read, and what decision could have consulted it and did not. In an SSO estate this is the question that matters, and it is a question about each service rather than about the centre.

10 · The three-question check

The model reduces to three questions, and they can be asked of any identity flow in about a minute.

What was performed? Name the mechanism that ran. A credential was validated, a policy was evaluated, an event was recorded. Be specific about where in the request it happened.
What would have to be true for the principle to be applied? State the effect in terms of the running system: the identity the decision used, the action the enforcement gated, the subject the record names. If the statement is about code that exists rather than behaviour that occurred, it is not yet an effect.
What evidence exists that it was applied? This is the one that does the work. Not the presence of the argument, not the return value of the helper, not the existence of the policy file or the log shipper. An observation of the running system, in the configuration that ships, that would have been different if the effect had not occurred.

The reason to insist on the third question is the asymmetry the companion field note describes. Where a mechanism is absent, the absence is visible in the code and somebody eventually asks. Where a mechanism is present and its effect is missing, the code has nothing to show, the mechanism has nothing to report, and every piece of evidence available to a reviewer attests to the mechanism rather than to the principle.

11 · Defensive controls

Where the principle is performed but not applied	Durable control	What to check on the running system
An identity is established at an edge and never consulted at the decision behind it	Resolve identity once and make the established value the only one any decision may use, rather than re-deriving or re-trusting it per layer.	For a sample of requests, which identity the decision at each layer actually used, and where that value was set.
A policy is evaluated and the decision does not gate the action	Place enforcement on every path that reaches the effect, and make the absence of an enforcement point an error rather than a fallthrough.	Which enforcement points an operation passed through, and whether the action description used matched the one the policy was written against.
A credential is accepted and its freshness is never established	Bind every credential to the exchange, with a nonce, a bounded timestamp or a challenge, so that a copied credential is not a usable one.	Whether a second presentation of a captured credential within its lifetime is rejected, tested rather than assumed.
An event is recorded against the identity presented rather than the identity established	Write the established identity into the record, and treat a record whose subject came from an unverified assertion as a defect in the logging path.	Whether a request carrying a forged assertion produces a record naming the forgery rather than the victim.
Accountability is assumed to follow from having logging	Define the events that must be attributable, then verify that each produces a record that names a subject unambiguously.	Whether a record of a single action supports the question of who did it, and what would have to be true for that answer to be wrong.

The first row is the one to fix first in an SSO estate, because it is the row that scales. Every additional service that receives an identity assertion without applying it adds another place where the centre being right does not help.

12 · Misconceptions and troubleshooting

"We have authentication, so we have authorisation." They are separate principles with separate mechanisms. A validated identity says who is asking and nothing about what they may do, and the decision still has to be made and still has to gate.
"The policy exists and it is correct." Correctness of the policy is a statement about the evaluation. Whether the decision gates the action is a statement about the enforcement point, and the two are independent.
"We log everything, so we have accountability." Volume of records is not attribution. If the subject in the record came from an assertion nobody verified, the record is confident and wrong.
"Replay is a transport problem." The transport carried a valid credential, which is what a transport is supposed to do. Freshness is a property of the exchange, and something in the exchange has to establish it deliberately.
"SSO centralises the risk, so centralising it well solves it." Centralising makes the mechanism more likely to be correct and makes each receiving service's decision to apply it more consequential, which is the opposite of solving it.

Troubleshooting comes down to naming which principle you are asking about. A defect described as broken authentication is usually one of three different things, and they are fixed in three different places. Establish which principle was performed, which effect is missing, and then look at the layer where the two should have met.

13 · Memory aids and practice checklist

Memory aid: three principles, and every one of them has a mechanism that can run without taking effect. Identification is satisfied when the established identity is the one used. Authorisation is satisfied when the decision gates the action. Accountability is satisfied when the record supports attribution. In each case, the mechanism running is not the same thing as the principle holding.

State the principle before naming any mechanism.
Name the effect in terms of the running system, not in terms of code that exists.
Follow the identity through every layer rather than following the credential.
For each operation, identify the enforcement point and the description of the action it used.
Wherever a credential is accepted, ask what makes this presentation different from the last.
Take one record of one action and try to fail it.
In an SSO estate, ask the identity question per service rather than about the centre.

14 · What the room teaches

The lesson, once: identity and access management is three principles, and a mechanism that performs one of them is not the same thing as the principle holding. The room is an introduction and it teaches the vocabulary and the distinctions. The reason the distinctions matter is that each one marks a gap where a system can look correct from every angle a reviewer can see and still fail the only question that counted.

Read alongside the rest of this series it connects to today's field note on a parameter that was accepted and silently not applied, which is the same gap in a library rather than an estate, and to the previous companion on JSON Web Tokens, which is the credential format that makes the identification stage concrete. The read-only sandbox field note covers the same question asked of a containment boundary: whether the boundary does what its description says.

Frequently asked questions

What are the three principles of identity and access management?

Identification, which establishes which subject is making a request; authorisation, which decides what that subject may do; and accountability, which makes it possible to attribute what was done to a subject afterwards. The room presents these as the principles IAM is built on, and each is invoked by a mechanism while only being satisfied by an effect.

What is the difference between performing a principle and applying it?

Performing is the mechanism running: a credential is validated, a policy is evaluated, an event is recorded. Applying is the result taking effect in the running system: the identity established is the one every decision uses, the decision actually gates the action, the record supports attribution. The mechanism produces an output either way, which is why the failure is silent.

Why is a replay attack possible if the credential is genuine?

Because the credential being valid is not the same as it being fresh. In a replay nothing is forged and nothing is decrypted; a credential is observed and sent again, and it is accepted because it is valid. What was never established is that this presentation differs from the previous one, which requires binding the credential to the exchange with a nonce, a bounded timestamp or a challenge.

Does single sign-on make identity management safer or riskier?

Both, in different directions. Centralising authentication means one place to get right, enforce and revoke, so the mechanism is more likely to be correct. It also means every receiving service depends on the assertion that arrived, and each of those services separately decides whether to apply the identity it was given, so a failure to apply one grows with the size of the estate.

Primary references and further practice

If you are working through the room, the exercise worth doing twice is the access control one. Solve it, then go back and write down which principle was being performed at each step, which effect the scenario depended on, and where the two would have had to meet. That second pass is the part that transfers to real systems.