Sunday, September 06, 2015
Tuesday, September 15, 2009
Before I go there, I wanted to capture my understanding of the password reset functionality.
- Why - Well if we are not noting down all the accounts we have created in life (either electronically or manually), it is possible that we are going to forget passwords for some accounts as we age. Even if you follow some techniques like having standard passwords across all your accounts, due to site limitations, change in word preferences, etc, you may not remember the applicable password for a site and so the lifesaver
- Why Not create a new account -
- a lot may be associated with that account in-terms of your reputation, information, etc
- site limitations of being able to associate a personal identifiers (may be email address or bank account number) with only one account
- the account id may be generated and can not be changed during your association with the site (SSN, biometric?).
- a lot may be associated with that account in-terms of your reputation, information, etc
- What - Password reset/forgot password is a functionality (a bit different from change password - where you remember/know your password) by which user or someone else on behalf of user is able to change the password without presenting their existing password. Again even though the discussion would focus on password, it would probably apply to any shared secret between user and identity provider
- How - As discussed earlier, the password reset can be done by user or somebody on their behalf. This process typically involves
- Verifying the requester's identity
- Ensuring that requester is authorized to request password reset (incase requester is same as owner of account, this check may be moot)
- choose a new password (either generated or accepted from requester subject to fulfillment of password policy)
- provision the password into the authentication system
- notification that new password can be used, if out of band password change happens (and possible security notification to account owner that password has been changed)
Classification Approach Based on the basics of authentication process, we know that we can verify user based on something they know, have or are. Now in order for the authentication to work we need to ensure same information is available to user and Identity Provider at the time of verification. This implies that prior to verification there has to be an acquisition process which can be classified based on when (at registration, during usage of account or out-of-idp/user account relationship) and from whom (user, Identity/service provider, third-party like credit rating agency, public data) the acquisition has been made.
The verification process itself can be classified based on the type of shared secret/credential along with other criteria like verification channel.
Based on this we can try to classify an approach for user verification which has been done for some of the most commonly used approaches. Please note that this is not an exhaustive list of various approaches in wild and just tries to show how the classification can work for some of the approaches being used in wild
|Registration||Account Usage||Out-of-band||User||Service Provider||Third Party||Know ||Have ||Are ||Single||Multi|
|What is your pet's name||Y||Y||Y||Y|
|When was your last withdrawal from account XXX?||Y||Y||Y||Y|
|Did you live at ZZZ on DD/MM/YYY?||Y||Y||Y||Y|
|Please provide your date of opening the credit card account||Y||Y||Y||Y|
|Send a nounce+ to Email Address *||Y||Y||Y||Y|
|Send a nounce to Cellphone *||Y||Y||Y||Y|
|One time Password cards for specific duration||Y||Y||Y ^||Y||Y|
* The classification may change depending upon the implementation but you get the idea.
^ If IdP is different from Service Provider
+ I do not want to use "temporary password" as it can be confusing
At present not all the permutation/combinations may be utilized but we may find other ways to combine these factors to create new methods. In addition to that, I have a feeling, we would figure out lot more ways of classification of the password reset process.
Why Even though this was just a thought exercise, I think we may be able to use it to study and compare various verification techniques. Given that people are already treating some combination of authentication/verification techniques as multi-factor (even though theoretically they may be single factor), it may make sense to develop more detailed classification technique so that we can compare various "multi-factor" techniques and ensure that we are not using pseudo-"multi-factor" techniques. Based on my limited knowledge, I have not run into any such framework but would really appreciate pointer in such direction.
Saturday, May 10, 2008
The quality of voice recognition (esp for numbers) technology is pretty high. This is pretty evident from the number of deployments in multi-level IVR menus. But , I think, the voice recognition capability of these IVR system is high because it is based on the premise that the user wants its voice to be recognized and false positives for these systems are probably still pretty high.
Incase of DLP, I think, the basic idea is to control accidental release of information and some simple data theft scenario. So, from that perspective adding Voice recognition to DLP makes sense esp for call center deployments.
Sunday, February 17, 2008
I would be looking forward to continue sharing with you all some of my experiences and thoughts in IAM space on this blog. I will be resurrecting my other blog which will concentrate on my life in India and other issues that I want to talk about.
Friday, November 02, 2007
- Cisco has finally seen the light and decided to enter the IAM space - I do not think this makes much sense given that they are not a software stack company, not even a software infrastructure company (like Symantec, Oracle, SAP, etc).
- Cisco needed a product to build identity based authorization into network and hence all its products - I think it is a result of reading too much by us entitlement management guys in to it and the way we would like to see the world.
- If externalization is being performed at administration level, then how do you expose widely different access control model (a SaaS site's model would probably be very different from Web Conferencing / IP Phones access model) through same interface without sacrificing usability, flexibility and asking users to learn a new policy language.
- If standardization/externalization is being performed at evaluation level, then how do you meet different performance requirements of different access control models through same generic engine. In addition to that keeping different implementations (on different platforms) for same policy evaluation algorithm with various performance tweaks can be tough.
Wednesday, September 05, 2007
Disclaimer - I have not worked on role-mining project and so most of the views expressed here are based on very limited understanding, a lot of arm chair thinking and some understanding of access management. I may be slightly biased against the role-management because I seem the end goal as Access Management and not role management and so far I have not had the "aha" moment for Role Management.
Coming from fine-grained access management background, I have always considered roles as a means to achieve the end goal of access management. Roles to me are an abstraction that we use to separate the policy modeling phase (roles being used to design policy model) and policy management phase (by managing user to role assignment).
But a lot of people do see the roles themselves as something important that need to be "mined" out of privileges. This could be, to some extent, a result of role-centric security model pushed by J2EE specification in past (and now through SCA Policy Framework) and the developers being comfortable with such models which tried to build a simple security model built around the idea of Is User In Role. Even though this works for most of the simplistic use-cases, some of the security model are more complex and that may warrants the need for XACML profile for J2EE to express the security policy to be enforced.
But there is another dimension to this whole discussion. There is a neat idea of Business Role and IT Role (equivalent to Basic Roles in NIST RBAC?) that seems to be gaining ground. The business roles are typically something that are defined by the Business/Organization (like Vice President, Teller, Trader, Foreman, etc) and IT Roles are defined by the application (like admin, user, auditor, etc). Most of the time it is expected that mapping the business roles to IT Roles would simplify the policy modeling and management. This could be a good justification for finding business roles (probably using top-down approach) and "mining" IT Roles (probably using bottom-up approach), if not already present, and mapping the two. So the problem of managing all the user-role relationships can be reduced to controlling user assignment to Business Roles which is something that is already in place in form of HR systems in many enterprise (Again it is probably already showing why I should not talk about things I do not have experience with and so feel free to correct my understanding)
Even though this approach looks great on paper, I am not sure how effective it is. In the few domains that I have worked, most of the business roles are contextual (for example - trader on a desk, teller at a bank branch). I have always thought that some of domains like manufacturing and retailing were closer to a standard role based entitlement model because of very well defined processes and role. But thinking more about it, even those may have nuances like supervisor of a specific shop. Similarly most of the IT roles are also context based. For example an admin role in a account management application would probably be given on specific accounts.
At the same time there are definitely applications ( for example any vice president can approve expense report ; show the admin menu only to an administrator) that can be fulfilled by generic roles.
Ultimately the use of NIST RBAC in an application boils down to how complex the role context is within the domain. In case the context is simple enough, it can addressed by building it in to roles so that you may have na_sales_mgr, emea_sales_mgr and so on. But most of us already know that such hacks, if not controlled, can become a recipe for role explosion and would ensure that you need a role management product.
The complexity of the context itself can make the role almost a secondary concept. For example let's take a case of a consulting firm working on large project. Such a project may have separate teams of developers, architects, infra guys spread over multiple geographical locations. Now such a scenario may be uncommon in IT consulting but I think some thing similar would be case in a auditing or investment banking where some of the multi-national M&A deals and company auditing take place. In the example earlier let's say the employee John Doe is assigned role DBA for the developer teams in New york and Seattle for the project Big Bang and Backup DBA for the architect teams in Europe (located in London and Paris) for the project Solve World Hunger. In this example the role itself is such a tiny part of the possible complex context structure (Location hierarchy, teams, etc). Now there may not be that many examples out there with such complexity at the context but at the same time such examples help keeping things in perspective.
To summarize I think we need to be clear about what is the problem we are trying to solve before starting on the role management path. If the end goal is access management then NIST RBAC should be looked at just one of the ways of policy modeling. But if the goal is to get the organizational hierarchy in control, then using a role mining tool to get some roles that are meaningless to business may not be right way to proceed and instead appropriate process must be defined and implemented for organizational hierarchy leaving the IT Roles out of scope.
Wednesday, August 29, 2007
So far I have thought about the Preferences and Entitlements as two separate notions that are not connected to each other. But today while thinking about a few things from work and some blog posts, I realized that there is more to the it than that meets the eye.
Before we go any further let's summarize the definition of terms for the purpose of this discussion
Preference is information that user makes available to resource / application to allow the resource /application to present information in a "user-friendly" manner. (I understand that this is very limited version of preference and there might be other better terms like Persona to describe the same concepts).
Entitlement Model (including model and data) is information that resource / application owner makes available to resource / application so that it can present information that user has access to.
Even though these definitions are not the standard, they are used here to drive the point of view that I am trying to explain. At some level we can view these two things as being about the same thing i.e. annotation of the user-resource mapping / relationship. There are a few implications that I could think of
- Entitlement Modeling as preference source and vise versa - One of the various source for the user preferences that an application can have is Entitlement Model. For example [James McGovern - Relationships and Authorization] - In case the Insurance application has modeled user's preferences (including relationships and their access levels /roles) in to its entitlement model, his preferences should be taken into account while determining the access for the user's son.
- One way relationship (do we have a word for these things) - If we treat the relationships as preference (i.e. I prefer to call John Doe my friend even though he may prefer to consider me to be an acquaintance) and have a standard way to integrate preferences into entitlement model, relationships can be just another preference that is supported by the entitlement model. Please note that incase preferences are modeled as attributes, downgrading relationships to attributes is something that can come back to bite when there are specific requirements wrt relationships.
- Provisioning - As discussed as part of entitlement and provisioning integration topic earlier, user's attributes for a given application can be based on the entitlement model the application enforces. Now one of the aspect of this is that some of the attributes /relationships being exported by entitlement model to provisioning model can be part of the self-service workflow to be managed as user preference.
- Extending Social Graphs - The relationships and attributes that form part of the identity provider trove, can be further enriched by providing additional preferences or refine the scope of relationships based on resources. For example I can be friend of a person in the context of specific resource (say flickr) but an acquaintance in the context of other resource.