Understanding JHED Access, Identity and Institutional Account Management

JHED is part of the Johns Hopkins institutional identity environment, but managing access involves much more than simply signing in.

A person may have a valid JHED identity and still need separate authorization for a specific application. An external collaborator may need a sponsored JHED account—or may be better served by a guest-access model. A user who changes roles may keep the same underlying identity while gaining or losing access to different institutional resources.

This independent editorial guide explains those broader access-management questions.

JHED identity is only one layer of institutional access

Institutional access usually involves several connected layers.

Identity

Identity answers a basic question:

Who is the person in the institutional environment?

JHED provides an institutional identity framework that can connect a person to supported Johns Hopkins resources.

Authentication

Authentication answers:

Can the person prove that they are associated with this identity?

A central authentication environment allows multiple institutional services to work from a common identity model.

Authorization

Authorization asks a different question:

Is this person allowed to access this specific application, resource or function?

This is where many apparent “JHED problems” are actually permission problems.

Governance

Governance addresses the larger operational questions:

• Why does the account exist?
• Who approved access?
• Which department owns the access decision?
• Does the user still need the permission?
• What happens when the user’s affiliation changes?

This site focuses primarily on these administrative and structural questions.

Explore the main topics

JHED account lifecycle

Institutional identities can change over time.

Explore how account provisioning, role changes, access review and deprovisioning fit into a broader lifecycle.

Read: JHED Account Lifecycle: Provisioning, Review and Deprovisioning

Sponsored accounts and external collaborators

Not every external person needs the same type of institutional access.

Explore the difference between sponsored JHED accounts, guest accounts and other collaboration models.

Read: Sponsored JHED Accounts vs. Guest Accounts Explained

Access governance

A central identity does not mean that one central team decides every application permission.

Explore the different responsibilities of:

• identity administrators;
• authentication services;
• application owners;
• departments;
• managers;
• resource administrators.

Read: JHED Access Governance: Who Actually Decides Who Gets Access?

Authentication vs. authorization

Successful sign-in and successful application access are not the same event.

This distinction is one of the most important concepts in institutional access management.

Read: Why Authentication and Authorization Must Be Managed Separately

A practical model for understanding JHED access

When evaluating an institutional access issue, separate the following questions.

1. Does the person have an institutional identity?

This is an identity question.

2. Can the person authenticate?

This is an authentication question.

3. Is the person authorized for the requested application?

This is an authorization question.

4. Who owns the decision?

The application owner, department or designated administrator may be responsible for determining whether access should exist.

5. Is the access still appropriate?

This is a lifecycle and governance question.

Breaking a problem into these layers can prevent an access issue from being incorrectly treated as a simple password or login failure.

Why external collaboration requires a different approach

Organizations frequently work with people who are not traditional employees or students.

These individuals may include:

• contractors;
• researchers;
• temporary collaborators;
• vendors;
• consultants;
• project participants.

The access model should match the actual business need.

If a guest collaboration model provides the required access, creating a full institutional identity may be unnecessary. If the person requires systems that depend on a sponsored institutional account, a different process may be appropriate.

The important principle is to begin with the required access—not simply with the question of whether a person “needs an account.”

The account lifecycle does not end after provisioning

Creating an account is only the beginning.

Over time, administrators may need to consider:

• changes in institutional role;
• department changes;
• new application requirements;
• removal of obsolete permissions;
• returning affiliates;
• the end of a sponsored relationship;
• deprovisioning.

A well-managed identity environment is therefore not just a collection of usernames. It is a process for connecting institutional relationships with the right level of access over time.

Browse the guide

This site covers:

• JHED access management;
• institutional identity concepts;
• sponsored JHED accounts;
• guest collaboration accounts;
• access authorization;
• application ownership;
• account lifecycle;
• access reviews;
• provisioning;
• deprovisioning;
• role changes;
• external collaborator access.

The goal is to provide independent, plain-English explanations of how these concepts fit together.

Important note

This website is an independent editorial resource and is not affiliated with, operated by or endorsed by Johns Hopkins University or Johns Hopkins Medicine.

For official JHED account actions, current institutional requirements, authentication or account-specific assistance, users should rely on verified official Johns Hopkins resources.

Editorial navigation:
About · Contact · Privacy Policy · Cookie Policy

Suggested cornerstone articles:

• Sponsored JHED Accounts vs. Guest Accounts
• The JHED Account Lifecycle
• JHED Access Governance
• Authentication vs. Authorization