Identity and Access Management Archives

Identity and Access Management (IAM / IdM) Services

In today’s complex world of ever-increasing web applications, passwords, governmental regulations, and auditing requirements, it is absolutely essential that all organizations, regardless of size, have a formal identity and access management system in place.

What Exactly Is Identity (Access) Management (IdM / IAM)?

Most simply put, Identity Management is a process that defines the “who, what, where, and how” of identity. It defines what an identity is within an organization, what the identity can do, and how to track and report on what the entity does. IdM is also referred to as “IAM”, or Identity and Access Management. This is also known as “AAA”, or Authentication, Authorization, and Auditing. Identity Management, or IdM / IAM encompasses all of the following:

Single Sign-on — One ID and one password/token/PKI/smartcard provides access to most or all applications in the enterprise.
Digital Identity (DigitalID) — Reducing and rationalizing multiple units of identity into a single entity, such as a specific username, or digital token, smartcard, dongle, cell phone, or PKI tool.
Provisioning — Registering and unregistering user access to applications and facility access points. Provisioning also includes all business workflow processes of approvals or denials.
Business requirements and use cases — Any successful IAM Program starts with charters, plans, and most importantly — requirements and use cases. We can help ensure these are captured and documented early on, so there are no budget and effort surprises late in the project.
Fine-grained authorization / entitlements — Permissions sets regulating what user or application can doonce access is granted.
Directory Services — IdM is built on the back of one or more directory services, such asLDAP, eDirectory, or AD. Directories may be standalone, metadirectories, virtual directories, of a combination of all three.
Authentication methods — Defines how users or applications may access a system.
Attestation, auditing and reporting — Tracking and maintaining records of all transactions by application and user, throughout each transaction point.
Strong authentication — Also known as “two factor” or “multi-factor” authentication and can include biometric, token, Kerberos, SAML, and PKI-based access.
Federation and Federated Identity Management — Digital Identity that is trusted across service providers, business partners, and multiple units within an organization. Federation is the “ring of trust” that allows Digital ID to cross boundaries.
Role Engineering | Role Based Access Control (RBAC) — Too many roles? Don’t know how many roles you even have? Need to match roles to business processes, and business processes to security and audit controls? Links Business Group LLC can find and analyze your existing roles and processes quickly, and put you on the road to RBAC, or “Role Based Access Control.”

Business Reasons for Identity and Access Management (IdM/IAM) Implementation

Regulatory Compliance
Significant cost reduction
Faster time to market for new applications
Developer efficiency
Application standardization
Increased business and IT process efficiency
Consistent means of applying security controls across all applications and processes
Full auditing and reporting for company applications
Eased integration with partners and suppliers
Improved end-user experience
Scalability and Integration

How Links Business Group LLC Will Successfully Implement Your New Identity and Access Management (IAM / IDM) Infrastructure

Links Business Group LLC consultants are equally at home in the program, design, and process sides of IAM / IdM — as well as the technical. Using our exclusive “Six Stages of IAM” or “IAM Six Stage Model,” we have the systems, processes, and expertise to get IAM done right — the FIRST time.

Not your first time around with an Identity and Access Management (IAM / IdM) Program? Have you (or your organization) attempted a large-scale, high profile IAM or enterprise IT project before and not achieved the desired results? I can help! In fact, I specialize in distressed, or “impossible” projects. Call today to schedule a complimentary no-pressure 30-minute consultation. I, Corbin Links, personally guarantee you that you will walk away from the call with useful, actionable information — even if our companies decide not to work together. The phone number is +1 800 507 3480.

Alternatively, visit our contact form.

Still unsure about Identity Access Management? Or maybe you just want to learn all you can about it within 3 hours, for small change? Want to see if this “Corbin Links person” knows what he’s talking about? Then the IAM Quick Start Guide may be just what you’re looking for!

Visit: http://corbinlinks.com/theiambook for information on my latest IAM book: IAM Quick Start Guide.

Already read the book, OR, need full IAM/IdM architecture and program services?

I look forward to working with you!

Need to fast-track your IAM savvy, but short on budget? Click the button and grab a copy of the IAM Quick Start Guide — Version 1.50 Gold Edition

Finding the Right IAM/IdM Business Systems Analyst (BA / BSA)

By Corbin Links

Q4 2013 Update:
It’s been a long while since this post was updated. I originally posted it back, …er…well a long time ago. (Early 2007?) Why the flashback? Well, much has happened — and not happened since then. What hasn’t happened? Any major reason to change the article. Yep, if anything, it’s even more relevant today.

Recently, I’ve been working with several clients to hire in business analysts (BA), also known as business systems analysts (BSA). In building the requirements and job requisitions, the focus has been too generic. The major disconnect many businesses still continue to have is that a good BA is a good BA. On a base level that’s true, but what isn’t true is that a good BA = a good Identity Access Management (IAM / IdM) BA. HUGE difference. In fact, the skills comprising a good Identity BA are cumulative and additive.

Since I’ve returned to active consulting in recent months, I find myself sending this article out to new and existing clients. It seemed like a great time to refresh it a bit and re-post it here. There are very few changes, most notably standardization on the acronym “BA” instead of “BSA”. The industry uses both terms heavily, but our more recent clients are using “BA” for “business analyst”. So “BA” it is.

Be sure to read through to the end and add your own comments and observations about hiring and managing Identity BAs. Now, I return you to the article below…

Hello Everyone:

A topic that comes up quite often — and rightly so — is the role of Business Systems Analyst (BSA or BA) within an Identity Access Management (IAM) Program. What is the right mix of skills? How much of the hiring decision should be weighted toward business acumen, light development (XML, web forms, etc.), and requirements management? How necessary are they? Can our IAM software vendor fill that role?

In short, the answer depends on your IAM Program, scope, organizational composition. Before I post a sample job description, some background is in order. First, an Identity BA is not like the traditional BA. A traditional BA works more closely with the various lines of business to determine which each business needs, what it is currently doing, what it wants to be doing in the future, and other factors as required by the stakeholders.

With all relevant information collected, the BA then collates the information, separating actual requirements from wish list, and subjective preferences. A process of collating, editing, synthesizing the core elements continues until business requirements, and functional requirements have been collected, refined, and organized. Once requirements are categorized, prioritized, agreed, and published, the BA hands the list off to the development or program team for development and implementation. (In the interest of time, I am glossing over many pieces of the process.)

Where the traditional BA model breaks in the Identity World, is that now the developers themselves are stakeholders, often with dramatically needs from one another. Application teams have their own requirements for integrating their applications within an Identity Access Management system or for consuming its services. Each individual application (which can number into the hundreds or even thousands for very large organizations,) requires its own analysis and requirements gathering project. The Identity BA must address all requirements, of all audiences.

In short, the Identity BA adds the dimension of detailed developer (and general Identity Management) knowledge to the level that he or she can do some light development work, especially in the area of Business Process Management (BPM). What is vital, is that the Identity BA can:

Collect all information
Extract actual requirements from subjective wish lists and “nice to haves”
Get stakeholder acceptance on just about everything
Synthesize Business Requirements from the whole
Derive Functional Requirements from Business Requirements
Document workflows and process in a visual model
Document future state (“to be”) workflows in a visual model
Derive User Acceptance Tests (UAT) from the Functional Tests
Translate future state workflows into executable business process.
And much more…

Sounds like a tough role to fill? It is. Compound the difficulty by the fact that really large Identity Programs may need several. To help ease the process, I am including a sample Identity BA job description. The usual disclaimers apply – it is not comprehensive for all possible situations, and your mileage will vary. However, when used effectively as a guideline, the list can greatly facilitate the hiring, placement, and effectiveness of this very crucial resource.

SAMPLE Identity BA Job Description

The goal for this position is to hire a person that is well-versed in both
business and functional requirements gathering. This is an exciting and
dynamic opportunity to work with key business units, developers, vendors,
and security analysts and help shape the future of our Identity and Access
Management (IAM) Program.

Duties Include

Collect application security requirements from internal developers
and external providers

Frequent meetings with stakeholders and IAM Program Team members

Collect business requirements from key business stakeholders

Validate all requirements, and separate key business requirements
from application wish lists

Translate business requirements into functional requirements

Translate functional requirements into Use Cases (UAT)

Maintain project requirements database

Maintain project UAT database

Create visual models of current "as-is" workflows (individual business
processes)

Create visual models of future state "to be" workflows

Assist in the translation of visual diagrams to XML as needed

Assist in the verification of IAM Product Change Orders

Minimum Requirements

3+ years as a BSA with at least one large (5000+ user) organization

Excellent written, verbal, chat, and email communications

Strong familiarity with IT Architecture concepts

Expert-level diagramming (Visio / Dia / UML)

Good familiarity with Project Management Methodology

Strong familiarity with Relational Database (RDMS) systems. (Not a
DBA, but comfortable with data structures.)

Good working knowledge of Internet security concepts and web
application architecture

Ability to meet deadlines in continually changing environment
Excellent prioritization

Strong self-starter that can work independently as needed

Overall understanding of high-level Identity Management concepts
(user ID"s, what provisioning is, etc.)

Basic understanding of compliance and audit requirements

Desired Skills (Optional)

Ability to read, create, and modify UML diagrams

Experience with XML message creation (SOAP, XML-RPC, etc.)

Creating and maintaining Business Process via BPM tools

HTML-based forms

Requisite Pro or similar requirements management tools

5 Ways to Gain Acceptance for Enterprise Programs and Projects

By Corbin Links

In any big IT or business program, user perception and acceptance makes all the difference between success and failure. Check out these 5 tips to improve your chances of success, and gain sweeping user acceptance.

Clearly summarize and articulate the reason for the program. This is not the time for an exhaustive laundry list, or discussion of technical whiz-bang features. Most if not all of the end-user community will care very little about the underlying technology or what vendor is providing it. Keep your message clear and simple. An example statement: Due to the feedback we have received about too many passwords, long times to sign on in the morning, overly long time to process your requests, etc. we are instituting a program here at XYZ Company, called “Identity and Access Management, or IAM for short. Note that the preceding statement places the emphasis on the end-user pain points. Each audience (end-user, program sponsor, auditors, developers, data security, helpdesk, desktop support, etc.) will require its own custom message.
Post the preceding statement on your company intranet and internal newsletters, along with guidebooks, screen shots, and videos. Think of this as “advance marketing”. It is critical to advertise well in advance of the launch. At a minimum, most Identity Management Programs include some form of user impact, such as password change frequency and/or complexity. Keep in mind there will be some measure of user impact, and plan accordingly.
Offer at least one informal “brown bag” session at each company facility. The fireside chat model works well. Start with a brief presentation of no more than six or seven slides, and then leave the rest open for questions and answers. They key is to provide a forum for users to air their questions, concerns, and grievances. Make impacts clear, and be open and honest about program benefits. Describe what the system can do, and what it cannot.
Clearly summarize the timeline. When, where, and how the system will be implemented. Who will be affected and when. If pilot or rollout groups are used (very common), then describe how the groups are selected, when they will be included, how much time will elapse between group deployment, etc.
Clearly state the “411” policy: where users can go for help, and what they should expect. “Support after the sale.” All it takes is one highly placed individual to have a negative experience and inadequate support to derail the deployment. Make it abundantly clear where users should go for help, how they use the help facilities (email, web-based forms, helpdesk issue entry systems, phone numbers, chat tools, etc.) Set up codes just to track Identity-related issues, and ensure that the helpdesk is ramped up, and staffed accordingly. Expect issues and general questions to initially spike way up, then plummet after the first 30 days. Set user expectations for response times.

I hope the preceding list is useful. Want more hands-on help getting acceptance for your big program? Call me today (via Links Business Group LLC) at +1 800 507 3480 to schedule a complimentary consultation, or fill out the contact form./p>