Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!
This is an example page. It’s different from a blog post because it will stay in one place and will show up in your site navigation (in most themes). Most people start with an About page that introduces them to potential site visitors. It might say something like this:
Hi there! I’m a bike messenger by day, aspiring actor by night, and this is my blog. I live in Los Angeles, have a great dog named Jack, and I like piña coladas. (And gettin’ caught in the rain.)
…or something like this:
The XYZ Doohickey Company was founded in 1971, and has been providing quality doohickies to the public ever since. Located in Gotham City, XYZ employs over 2,000 people and does all kinds of awesome things for the Gotham community.
As a new WordPress user, you should go to your dashboard to delete this page and create new pages for your content. Have fun!
Employees are also customers.
Students are also teachers.
Contractors can serve in many roles.
Some individuals could be all of the above.
Imagine a student, who is a student teacher, who is employed by the university in a work study job in the bursar’s office, and works part-time for a contracted research laboratory. Each of these roles constitute a separate relationship with the university, and could require separate levels of access to computing resources.
Traditional identity management practices and products could be tailored to effectively grant, manage and remove access associated with each relationship, and potentially even correlate all the access rights back to the same identity. To accomplish this, an army of consultants may define service catalogs, roles, and custom business processes. Even after all that, they would likely fail to properly govern the relationships that are associated with this student/teacher/employee/contractor.
To properly govern identities who maintain multiple relationships with your organization, you must also be able to represent multiple sets of relational attributes as well. This includes multiple titles, employment types, states (active/inactive) and relationships such as manager.
If you are struggling with governing relationships, I’d love to hear more about your use cases.
At Burton Catalyst in San Diego this year, the identity analysts framed a future of “pull” provisioning. The “pull” model for provisioning states that access is only granted (and possibly provisioned) at the time of request and that all the information necessary to model the user for the application should be “pulled” from an available source.
I love the theory and believe we as an industry should strive towards this goal, but there are a few big holes to fill…
What’s required by the application to provision a new account?
My immediate thought when I heard Bob Blakley’s presentation was that there is no way that all the necessary information can be pulled when needed. And when I say all the information, I mean identity and authorization attributes as well as compliance related artifacts such as approvals and separation-of-duty policy evaluations and identity assurance results.
Take for example a pure pull provisioning operation for a SaaS CRM solution. Imagine that I have just transferred from the Services Department to the Sales Department and I should now be able to access the SaaS CRM solution to which my company subscribes. With a purely pull model, I should be able to navigate to the CRM solution through our Federated SSO solution and instantly get access without any obvious “provisioning” operations occurring. For our CRM system, and actual account needs to be created.. much like the most popular online CRM solution.
How would this work?
When I navigate to the CRM solution, the federated access management solution redirects me to my IDP to authenticate me and sprinkle some attributes (assertions) on my token and then redirect me back to the CRM site. It would recognize that I have never been to the site before, and proceed with provisioning operations.
Here’s where the interesting part starts to happen. What information is needed by the CRM system to create an account and authorize me throughout my session? Looking at the illustration below, the majority of the information could be gathered from the Identity Provider (IDP) through federation services and could be pre-populated on the a SAML token. Other information, like enterprise roles, might need to be gathered from another source, either directly or via the IDP attribute service. Lastly, there is some information that might only be known by the user, and this could be gathered at during the first request for access. (I know that authentication Q&A are antiquated, but a number of sites that support federation or OpenID still ask). Notice that for items like first name and last name, there could be different sources and different values. Also notice that some attributes will require attribute mapping (email -> emailAddress) or attribute value transformation (“CRM Admin” -> “Admin”)
At this point, the orchestration of required attributes has been completed, and the actual creation of the my user account can commence. But how, and by what service? Looking at Ping’s solution (p.252) for provisioning, as well as Symplified’s, they both perform “last-mile” provisioning operations on the SP similar to any connector framework. To accomplish this, there must be pre-arrangement through the definition of a target (LDAP or Database), and schema mappings from the source of information (SAML assertions or othewise) to the application. This sure looks an awful lot like how we used to configure adapters in Sun IDM… just with fewer supported target applications. Also, notice that I put “Provision” in quotes… I’ve always said that provisioning = process, and there’s a fair amount of process missing in this scenario. I’ll cover that in a future post.
Bob Blakley states that each actor in the orchestration will audit the changes that occur… This seems like a loosely traceable audit trail. (I’ll cover this more in a later post)
You can see from my simple description of attribute sourcing (and Nishant’s better description) that there will be significant configuration needed to establish federation relationships, attribute sourcing, attribute translation, and provisioning targets with schemas. Today, these configurations would need to be established for each environment and even with the use of a bag of standards, be fairly complex.
In future posts I will expand on this post and discuss the complexities of implementation, and the lack of compliance related activities.
Recently, a good friend of mine asked for my advice on online privacy. He was considering promoting a cause to raise awareness and funding for research relating to a loved one’s illness. I recommended he ask himself some of these questions that go into my thought process:
1. Do I care if everyone knows?
(The clean livin’ factor)
For most social media updates, like on Facebook or Twitter, ask yourself if you really want all your friends, and their friends seeing your moderately inappropriate update or risque photo. …and ask yourself who will they tell that is not in your “controlled” social network. If your concerned at all about a post, don’t post it. It will be public, permanent, and pervasive.
2. Could the information be used negatively against me or anyone I have a relationship with?
(the crazy uncle factor)
Listen up everyone. You might be alright with posting “that picture” from Vegas, but your friends in the shot might not be, so don’t post it. …and if you do, don’t tag them in it without their permission. And while I’m on my soapbox, Facebook should facilitate authorization of identity-object association, but probably never will.
You can see this issue with non-digital communications as well. I always cringe a bit when I see those car stickers that shows a child’s name overlaid on their favorite sport. That parent has just identified their child by name, and told everyone their favorite activity and their school. Do they also have stickers you can buy to indicate that they also like Snickers and puppies?
3. Is the information available already to people who really care?
(the big brother factor)
I know we all like to ignore it, but items like the value of your house, pictures of your house, pictures of you, your credit score and even seemingly private information like your travel patterns, are available for free or for fee. (cell phone providers sell anonymous data about users, but this data is easily “re-identified” by looking at the data: where are most calls made from? My house and my work, which are public)
So, if others are sharing or selling your information, why wouldn’t you?
4. What’s the % chance that anyone will find the data, care about the data, and use the data for negative reasons?
(the needle in the haystack factor)
Of all the people in all the world why you? Are you a target (because you don’t pay your bills, or are a crazy right-wing evangelist)? If so, then you know it, and you should behave in a manner that keeps you “under the radar.” If not, then you’re a needle; the risk is low (but still there).
5. Does releasing this information make it easier for anyone to steal my identity?
(the FUD factor)
… IMO, the answer is a qualified no. Most identity theft occurs from some other avenue than direct information sharing, and you are more likely to be exposed by a corporation that has information about you, or the waiter at your local pizza place than you are with your actions.
6. Do the benefits of making the information public outweigh the risk?
(The real question)
This is something that you will have to decide for yourself.
Reflecting back to the original question from my friend, will his loved one benefit from a public indication that they are sick? Will the benefits of increased funding of research, sympathy and support from family and friends, and their positive impact on the community of others afflicted with the disease outweigh the risk?
Here a couple of great examples of the people who share their story and provide tremendous benefits (even in the face of some controversy) to their audience.
Welcome to SimplyIdentity.com where we aim to provide you with the latest information, commentary and advise on Identity Governance and Privacy.
We will try hard (no really this time) to keep the content of this blog up to date and relevant… and simply explained.
Thanks for visiting SimplyIdentity.com.
Our goal is to provide you with simple explanations and examples of current and emerging trends in Identity Governance and Privacy.
I’ve been in the Identity and Access Management industry for 8 years working in a number of roles, such as support services, engineering, training and product management. I started my career in Identity Management at Waveset Technologies/Sun Microsystems and served at the Sr. Product Manager for Sun Identity Manager, Sun Identity Manager Service Provider Edition, and Sun Role Manager (now Oracle Identity Analytics). Currently, I am Sr. Product Manager at SailPoint Technologies working to drive innovation and thought leadership into the emerging Identity Governance Market. When I’m not working, you might find me chasing my two boys, playing with my iPhone, cycling or playing some basketball.