One Access Decision From Identity, Membership, and Entitlement

1. A login is the beginning of the decision

A user signs in successfully and opens a licensed feature. Several questions remain: is the session still valid, is the user still a member of the selected tenant, does the resource belong to that tenant, and does the requested operation fall within both the user's permissions and the tenant's entitlement?

Applications often answer those questions in different places. A login handler checks identity, a navigation component hides unavailable features, and a billing integration updates a subscription flag. The gaps appear when an API request reaches a resource without repeating the complete decision.

EntryPin's identity and licensing direction motivates a composed access contract. The proposal in this paper is to make each necessary condition explicit and evaluate them for the action being attempted. OWASP recommends denying by default and validating permissions on every request. Those principles support the enforcement boundary here; they do not choose the application's membership or licensing policy. [1]

2. The decision model

For a proposed action, let the inputs describe the authenticated principal, current session, tenant, resource, operation, and policy version. The decision permits the action only if every required condition holds. An unknown condition is not silently treated as true.

The rule can be expressed without depending on a particular identity provider:

Permit only when the session is valid, membership is active, the resource is in scope, the operation is authorized, and the required entitlement is effective.

Each term has an owner. The authentication system establishes the principal. Membership records establish the tenant relationship. Resource data establishes ownership. Authorization policy establishes allowed operations. Licensing establishes feature availability. Keeping these authorities separate prevents a paid subscription from becoming an identity credential or a client-supplied tenant name from becoming proof of membership.

1. 1. IdentifyResolve principal and valid session.
2. 2. ScopeBind tenant, resource, and operation.
3. 3. EvaluateCheck policy and entitlement.
4. 4. EnforcePerform only the allowed action.

An explanatory reason should accompany denial internally, but the public error should reveal only what the caller is permitted to know. A response that distinguishes “resource exists in another tenant” from “resource absent” can expose information before access is granted.

3. Worked example: membership changes during a session

Consider a synthetic team application in which a member opens an export screen. The user has a valid session, active membership, and permission to export. A tenant administrator then removes the membership while the browser remains open.

The browser still has the screen and may retain an earlier feature response. When it requests the export, the server must decide again using current membership or a deliberately bounded freshness policy. Treating the earlier screen load as authorization would let the user act after removal.

The final check should be coupled to the protected action as closely as the storage architecture permits. If membership is checked in one service and the export starts much later in another, the system needs a documented rule for that interval. A short-lived authorization decision can bound exposure, but it does not provide instantaneous revocation.

Long-running work requires another policy choice. Does removing membership cancel a queued export, prevent retrieval of the completed artifact, or both? Those are distinct operations. The result must be enforced at download time as well as at job creation if the product intends removal to terminate access to generated data.

4. Entitlements need effective-time semantics

A subscription record can be active, scheduled to end, suspended, or pending synchronization. A single Boolean loses the reason and timing of the transition. The proposed entitlement record therefore distinguishes the feature, applicable tenant, effective interval, source revision, and any explicitly authorized grace behavior.

Grace periods should be product policy rather than accidental cache behavior. A team may choose to permit low-risk reads briefly during a licensing outage while denying new exports or administrative changes. Another product may require current entitlement verification for every protected action. Both choices carry costs that should be explicit.

A billing notification is evidence of a subscription event, but integration delivery may be delayed or repeated. Processing should preserve ordering information or resolve current state from an authoritative source. Arrival order alone is a weak basis for deciding whether an older event supersedes a newer entitlement.

5. Central decisions and embedded claims

A centralized decision service can apply current membership and entitlement state consistently across several applications. Its costs are dependency availability, request latency, and the need to define behavior during an outage. Merely centralizing code does not guarantee consistent policy if callers can bypass the service.

Embedding claims in a session or token reduces repeated lookups and allows some independent verification. Its cost is staleness: a removed membership or changed entitlement may remain represented until the credential expires or is otherwise invalidated. Shorter validity reduces that interval but increases refresh traffic and dependence on the issuer.

A hybrid design can use stable identity claims from a credential while evaluating mutable tenant relationships and high-impact entitlements closer to the resource. This paper recommends selecting the freshness boundary per operation, based on the consequence of stale permission. It does not prescribe a universal token lifetime.

The decision record should retain enough context to explain which policy and state versions applied. Routine logs need not contain full credentials or raw identity-provider responses. Recording excessive input can create a separate disclosure risk without improving the explanation of the decision.

6. Verification and unresolved questions

Tests should exercise every condition independently. A valid session with the wrong tenant must fail. An active subscription with an unauthorized operation must fail. A permitted action against another tenant's resource must fail. The expected outcome should be checked at the server boundary rather than through whether a button appears.

Concurrency tests should remove membership or entitlement between screen load, job creation, execution, and artifact retrieval. Outage tests should confirm that grace behavior matches the declared policy. Repeated and reordered subscription events should not restore an obsolete entitlement accidentally.

Useful operational measures include decision failures by reason, the age of state used for a decision, and the elapsed time from revocation to effective denial. These are proposed measurements; this edition contains no EntryPin evaluation data. It also leaves identity proofing, account recovery, and provider-specific session protection to separate design work.

7. Conclusion

A coherent access system makes the protected action the unit of authorization. Identity, membership, resource scope, operation permission, and licensing remain independent inputs to that decision. The resulting contract is easier to test than a collection of unrelated UI flags because a reviewer can vary each condition and observe whether the action occurs.

For EntryPin, the strongest next demonstration would be a complete revocation scenario across a live session and a queued operation. That would show the actual freshness guarantees of the design and expose where the product must make an explicit tradeoff between availability and immediate denial.

References

1. OWASP. Authorization Cheat Sheet. Default denial and request-level permission checking discussed in Section 1; consulted September 6, 2026.