However, this is explicitly not about user accounts and what some may call “digital identities”. It’s also not about non-human identities (NHIs), workload, service, machine-to-machine, or customer accounts. 

There are a lot of great articles already written on each and every one of these identity types by thought leaders, so I’d like to address the neglected others.

So, if this article is about identities, but none of the above, then what’s this article about? This is about other constructs that are fundamental to all Identity and Access Management programs, and to their related tools and applications. I’m referring to the identities of constructs like groups, applications, policies, networks, etc.

Identity Constitution

Allow me to simplify the constitution of ‘Identity’ into having three parts: 

1. An identifier (as unique as possible)
2. Attributes, which provide further differentiation, context, etc.
3. Relationships (e.g., “belongs to”), which can be documented as part of #2

“My dog’s name is Lola” ← These five words already encompass the three parts above:

1. Her identifier: Lola
2. Attributes: type: Dog
3. Relationships: owner: Me (although, if Lola could talk, she’d tell you her human is my wife)

An example of a non-living object is “my lucky t-shirt”. I’ve had this t-shirt for years, and it’s green, and it has a print of mountains with “Colo ‘rad’ o” written above (I’m a dad, I love it). At home, I may say, “have you seen my lucky t-shirt?”, and in the context of my family, chances are they’d know which one I’m talking about. If my daughter is not sure which t-shirt I’m talking about, she may ask, “what color is it?” (It’s green, an attribute). Life gives us an extensible schema to define any number of attributes to identify objects.

In the examples above, I shared the ‘Identities’ of two objects. The point is to ‘identify’ them.

If we turn to IAM-related objects, we can look at groups as in immediate need of proper identification. A group’s system identifier may be “xyz123”, attributes may include Group Name = “App X Users” (this may be considered the identifier, to the human eyes at least), and Group Description = “Accounts with access to App X”. Is this sufficient? Perhaps initially you’ll think “absolutely”. I’d argue that there’s a rich group identity hidden behind the ID, Name, and Description for this group. 

The IAM systems I’m most familiar with allow me to define a rich, extensible schema for accounts with many different attributes and even different attribute-types (string, Boolean, array, etc). This is excellent and much needed. In the last few years, the ‘group schema’ became available, so I may now define a Boolean value ‘For SSO’, ‘For SCIM Provisioning’, or ‘For Policy’. In addition, I want to define ‘Pushed to App’ as a Boolean value, and if TRUE, then ‘App’ (string type, as I can’t define an App object relationship).

But, there’s no extensible schema for ‘Apps’, or for ‘Group Rules’, or ‘Policies’, or ‘Networks’, etc. Lots of opportunities here to elevate the schemas of other objects to a whole new level. 

The CMDB is an Identity Management system

It follows that the system of record for constructs such as applications, systems, and perhaps groups is actually an IAM system, but for constructs other than accounts.

A proper CMDB will contain the creation date for any of its configuration items (CIs), its reason for being, its location, and, importantly, its relationships to other CIs.

A Source of Truth

One way to make your IAM system compliant and elevate its security is to delegate account creation to the correct source of truth. HR-driven provisioning is one example of this. If the IAM system delegates employee account creation to a correlated HR record, and the permissions to create accounts are removed from humans, a bad actor would have to shift their tactics to the HR system in order to create an account, which would likely require creating a role requisition, an applicant account, and then a hire/onboarding process.

Similarly, if the base attributes for a group, application, or other IAM construct are established and properly governed by the right source of truth, then the entire identity fabric will be more secure and compliant, but it’ll be like a self-maintaining organism, keeping the parts that are needed and auto-shedding those that have come to the end of their useful existence. 

Naming Conventions Don’t Work

You’ve likely implemented or have seen many naming conventions implemented to address this very topic. In my experience, a naming convention typically encodes attributes into the name (perhaps into a `Description`) with the intent to give more context to the object. This may work in some situations and it may help humans visually inspect the object. The problem begins when these existing encoded dimensions change or no longer capture the entirety of the object’s schema. When faced with this challenge, proper hygiene means renaming all existing objects, or, in the more common scenario, breaking the naming convention altogether. The end result is heterogeneous names and paralysis due to confusion and the need to research.

Suggested Actions

If you have access to an extensible schema for your objects, use it. Give those objects a rich identity that empowers a complete lifecycle of the object, from creation to decommissioning.

In the case of our Lola, she has her tag on her collar with her name and our cell phone numbers. However, she also has a microchip that extends the schema of her attributes to include our details, her vaccinations, etc. in case she gets lost and loses her collar.

If you’re building or managing IAM software, expand the universe to enable rich schemas in the system. Some of us may want to have a “lucky” group/policy/agent, and we certainly want better ways to identify and protect our Lola’s.

Disclaimer: The views expressed in the content are solely those of the author and do not necessarily reflect the views of the IDPro organization.

About the author

Pablo Valarezo is an Identity practitioner building and modernizing secure IAM programs over the last decade. His primary focus has been in the workforce side of IAM. He came to Information Security via system administration, project management, and audit and compliance.

The post The Identity of Everything… Else appeared first on IDPro.

The Internet Identity Workshop meets twice a year and publishes proceedings for those who were unable to join. IIW34 was held at the end of April, and our own Heather Flanagan led a topic entitled “What do you wish you’d known when you first started in identity?”, which is a topic near and dear to all of us in IDPro. Here’s a quick overview of some of the thoughts participants came up with (I deliberately did not edit the bullets captured from the whiteboard):

Wish I’d been there for the live discussion! These are some of the same challenges we’ve all had throughout our careers. Fortunately, we now have IDPro to help newcomers to the identity and access management industry with some of these challenges, starting with our Body of Knowledge, which addresses many of the questions above.

The green statement added to the first bullet stating that there’s “always a new context to solve for” especially rang true for me. This is a workspace that is constantly evolving, and you’re never really “done”.  That definitely feeds into the “Don’t worry solve everything” idea. Huh? Wait, what? Had to check with Heather on that one, and in the heat of the moment, words were missed on the whiteboard. The discussion actually went along the lines of “Don’t worry about solving for everything; every process is an evolution.” Okay, that makes more sense. To look at identity from an agile perspective, this is clearly a practice that benefits from iteration as new contexts continually show up.

Not captured on the whiteboard, but every bit as relevant, IDPro member Joe Andrieu said “I wish I knew that identity is how we recognize, remember, and respond to specific people and things. I also wish I knew that different people have fundamentally different mental models of what identity means. And we often talk past each other even as we honestly try to communicate.” So true! He also shared links to his Functional Identity Primer and Five Mental Models of Identity articles with the group. Definitely worth a read, folks!

What else do you wish you’d known when you got started in this space? Let us know in our Slack workspace and keep the conversation going.

Greg Smith

Chair, IDPro Editorial

Radiant Logic

Greg Smith is a Solutions Architect with Radiant Logic. He has been implementing Identity & Access Management solutions for over 35 years. He holds BSEG and MSBA degrees from Bucknell University, where he also began his professional career before moving into the Pharmaceutical industry in 1996. After a 25 year career there, he recently retired from Johnson & Johnson, where he led the engineering team for J&J’s single sign-on, risk based authentication, multi-factor authentication, access governance, directory synchronization and virtualization, provisioning automation, and PKI services. He has spoken at Identiverse® and other industry events on numerous occasions. He was recently CIDPRO certified and is also a founding member of IDPro, where he currently chairs the editorial committee.

The post What do you wish you’d known when you first started in identity? appeared first on IDPro.

These packages include one Identiverse event ticket, donated by Identiverse, and up to $1,000 for expense reimbursement, fully funded by generous donations from IDPro members.

“We are excited to be able to offer these Diversity & Inclusion Packages to the identity community. I have been a firsthand witness to the impact these values are having on this industry and am very proud of our organization for being able to support this effort.” — Heather Vescent, Executive Director and President of IDPro.

To be considered, please submit a personal statement of no more than 300 words to director@idpro.org by 11:59 PM PDT on June 7, 2022. Your personal statement should answer the following questions:

1. Can you please share a little bit about your background?
2. How did your interest in identity come about?
3. What do you hope to learn at Identiverse 2022?
4. Why are diversity and inclusion important to you?
5. Are you willing to write a brief blog post or be interviewed about what you learn at Identiverse 2022? 

Please include any social media links in your personal statement. 

Our vision at IDPro drives us toward enabling a diverse, supportive, and inclusive identity community and we are grateful for our dedicated members who are helping us achieve this important goal. We look forward to reviewing your submissions and we hope to see you at Identiverse 2022!

The post Announcing IDPro®’s Diversity & Inclusion Packages for Identiverse® 2022! appeared first on IDPro.