Identity and Access Management

Authentication establishes that someone is who they claim to be. Authorization determines whether that identity may perform a particular action on a particular resource. A successful sign-in does not settle the second question. OWASP treats these as distinct responsibilities and recommends checking permissions on requests, not relying on an interface to hide restricted actions. OWASP's authorization guidance

That distinction becomes clearer through ordinary work. Someone may be allowed to read a proposal but not approve it. A buyer may place orders for one branch without seeing another branch's records. A contributor may edit a draft without being able to publish it.

Even a label such as “manager” leaves questions unanswered. Manager of which team? Responsible for which locations? Allowed to approve what? For how long?

We help make those questions explicit before turning them into controls. Otherwise, a broad role can quietly carry more authority than anyone intended—or leave people repeatedly asking for access that their work genuinely requires.

The goal is not to make every person an administrator. It is to make appropriate access understandable and dependable.

An access plan starts with people and the work between them. We ask who needs to participate, what they are responsible for and what information belongs within that responsibility.

Useful questions include:

• Who can invite someone, approve their participation or change their role?
• Does access belong to a person, an organization, a project or a specific assignment?
• Which actions require additional approval or verification?
• What changes when someone leaves a team but remains a customer?
• Who helps when a legitimate user cannot get in?
• Which decisions must remain visible afterward, even when the person can no longer sign in?

These are governance questions as much as technical ones. An application can enforce an agreed rule; it cannot responsibly invent who should have authority within the business.

We work with clients to define those relationships and with their technical or security specialists where the situation calls for them. The result should be a shared understanding that can be explained, implemented and tested—not a permissions spreadsheet understood by one person alone.

This is also where Portal Design and identity work meet. The portal makes a person's responsibilities visible. Access management helps ensure that those responsibilities are respected underneath it.

When an equipment-maintenance business brings an external contractor into its work, we help define access around the assignment and the responsibilities—not simply around the creation of an account.

The contractor needs the instructions, location details and relevant service history for those assignments. They do not need unrestricted access to every customer record. They may need to submit a completed-work report without being authorized to approve their own invoice or change the customer's contract.

“Give the contractor an account” is therefore only the beginning.

Together, we would establish who approves the invitation, how assignments are connected to the account and which information is necessary for each task. The interface should help the contractor recognize the correct customer and job. The implementation must enforce those boundaries even when someone follows an old link or requests information outside the visible navigation.

Then we examine what happens when the work ends.

Removing an assignment may need to end access to its documents without erasing the report that the contractor submitted. Ending the relationship may require access to be withdrawn across connected tools, not only from the first screen. A delayed update or failed connection needs a visible owner and an agreed response.

We would test allowed actions, denied actions and changes in responsibility—not simply demonstrate that the contractor can sign in.

Access has a beginning, a context and an ending. We work through each with the people responsible, then verify that the implementation carries those decisions beyond the visible interface.

Single sign-on can let someone use one sign-in arrangement to reach multiple assigned applications, rather than maintain a separate sign-in experience for each. The supported applications, identity provider and configuration still matter. Microsoft's single sign-on overview

For a client, the useful question is what that connection should accomplish. Is an employee moving between internal tools? Is a customer moving between a store and a service portal? Should a business account remain distinct from someone's personal participation?

A shared entrance does not mean every connected system should expose the same information. We still need to determine which account belongs to which relationship, how access is assigned and removed, and what happens when those systems disagree or cannot communicate.

We also examine whether an apparent simplification creates a new dependency. If the sign-in provider becomes unavailable, who is affected? What can support staff do safely? Which responsibilities belong to the provider, the client and the implementation team?

Systems Integration helps connect the services. Identity and access work determines the boundaries those connections must preserve.

A lost device, changed email address or expired invitation should not leave a person guessing whether they have done something wrong.

We consider recovery alongside registration and sign-in: the language people encounter, the verification appropriate to the situation and the help available when an automated route is insufficient. Accessibility belongs here too. A protective step that a person cannot use still needs an appropriate, carefully designed resolution.

Clear communication must also respect privacy. For example, a password-reset message should avoid revealing whether an account exists to an unauthenticated requester. Helpful guidance and protection of account information need to be designed together. OWASP's password-recovery guidance

There is no universal recovery policy for every service. The consequences of access, the people using it and the responsibilities of support staff affect the solution. We establish those needs and involve appropriate expertise rather than treat account recovery as a decorative form or an improvised exception.

Identity work does not always require a replacement platform. The existing tools may be suitable while their roles, invitations, approval steps or connections need attention.

We can help assess that arrangement, clarify its rules and scope focused improvements. A larger implementation may be appropriate when the current foundation cannot support necessary relationships or be maintained responsibly. The decision should come from the situation, not from a preference for a particular identity product.

Our wider cycle—Discover → Define → Explore → Design / Develop / Market → Learn → Advance → Discover—gives the work room to learn and return. Within it, an identity engagement might investigate current access, agree a smaller set of meaningful roles, explore representative journeys, implement changes and learn from their use. It is not a requirement to run every activity at the same scale.

Desirability asks whether people can accomplish legitimate tasks with dignity and clarity. Technical feasibility asks whether the chosen systems can enforce the agreed boundaries. Viability asks whether the organization can operate, review and maintain the arrangement over time.

We also ask what the evidence proves. A successful sign-in demonstration is useful. It is not evidence that every permission, recovery path or connected account change behaves correctly.

The work can leave behind more than configuration: an understandable account and access map, agreed approval rules, tested scenarios, known limitations and practical operating guidance.

Our client-empowerment approach can include living workbooks explaining invitations, role changes, recovery and escalation. As services and teams evolve, that guidance needs attention alongside the software.

Ongoing care may include reviewing access changes, maintaining connections and investigating problems within an agreed scope. It does not imply unlimited monitoring, a guaranteed response time or a claim that no unauthorized access can occur. Specialist security and compliance responsibilities must be identified rather than absorbed into a vague promise of “secure.”

The connections extend into Membership Website Development, where access follows participation and benefits, and B2B E-commerce Development, where one company account may contain several people with different responsibilities. The common question is not simply who has a login. It is what relationship that login represents.

You might need a new account system. You might need to untangle an existing one, improve recovery or work out why staff keep sharing access to get their jobs done. We can help define the problem and deliver or co-create an appropriately scoped response alongside your team and specialist partners.

You do not need to arrive with every permission decided. Bring the situation: who is trying to do what, and where the current arrangement stops making sense.

Contact Us to work through it together.