In every identity project the topic of user account naming conventions comes up.  We have seen just about every convention possible.  More often than not, environments have more than one convention because over time they changed the convention but grandfathered in the existing accounts.  Inevitably I’m asked, “What is the best user account naming convention for us to use?”

There is no such thing as an absolute right answer to this question.  However, based on the needs of your organization, there is a best practice approach.

When choosing the convention for user accounts, you should take into account these drivers:

• Usability
• Security
• Administration
• Audit

Each organization must prioritize these drivers.  For some organizations the IT department can set the priority whereas other organizations have the priority set by the business or by external drivers such as compliance laws.  First, let me explain the drivers so we are on the same page.

Usability:  Usability is concerned about the end user.  An organization most concerned with keeping their customers happy will set usability as the top priority.  The typical account naming convention in this scenario is your name-based convention such as “tmoreland” or “troym”.

Security:  Security is concerned about unauthorized access.  The concern is the ability of user’s to guess login names and therefore knowing half of the authentication credential.  The typical account naming convention in this scenario is a system generated account name that is not directly linked to identity data in any way.

Administration:  Administration is concerned about ease of administration.  The concern is the ability for “Help Desk” users to quickly and easily find user accounts.  The typical account naming convention in this scenario is one based on full name such as “Moreland, Troy B.” or “Troy Moreland”.

Audit:  Audit is concerned about auditing and reporting system and application access.  The concern is the ability to run reports to show the history of access for specific users.  This requires a naming convention that doesn’t change (such as a primary key in a database) since access logs normally only store user account names and not a GUID.  The typical account naming convention in this scenario would be using a unique identifier from an authoritative data source such as employee ID for staff or student ID for students.

**RECOMMENDATION:**  Since there is no right or wrong answer, here is our recommendation.  The convention you use should NOT allow for user accounts to be renamed.  Regardless of what convention you choose you must be able to enforce a policy to restrict account name changes.

There are two primary reasons that make up the basis of this recommendation.  For one, we strongly agree with the “audit” driver.  Whether or not your organization is required to report on access due to compliance laws or not, you should always give yourself the ability to research access based on account names.  If account names change during the lifecycle of an account, building access reports becomes nearly impossible because you have to know ALL user account names that person ever used, not just the current account name.  The second reason is a concern when implementing an identity synchronization solution.  If you are tying together your disparate directories such as Active Directory, eDirectory, OID, SUN Directory, etc., account name changes can cause synchronization issues because this operation is not your typical “modify” event.  Account links could be lost and subsequent modify operations could fail.

In short, we recommend the “audit” approach.  If this absolutely won’t work in your organization, you could attempt a hybrid that perhaps includes initials (e.g. TM123456).  Just do what you can to enforce a policy that does NOT allow renames.

For more information on identity synchronization, please Contact us today.

We have all heard the stories about businesses struggling to stay viable as we deal with the current economic slump. A topic that has been of particular interest to many of our existing and prospective customers in recent months has therefore been _cost reduction_.  While the Identity Management space covers a lot of ground, one particular area that can have a big impact on cost is Password Self Service.

The challenge for today’s user is that they have too many passwords to remember which means that users forget those passwords (or use insecure passwords - a topic for another post). This leads to increased costs and decreased productivity as users have to take the time to call the help desk to gain access to the systems they require to perform their duties.  Add to this Forrester’s estimate that the average help desk cost to a business is $70 per call, and one can quickly see that this can be very costly indeed.

The way to solve this problem is to implement a mechanism for Password Self Service that puts the onus of responsibility for changing forgotten passwords on the user thus allowing for fewer IT staff to manage the environment.  There are numerous approaches to this challenge such as web based kiosks, telephone interactive voice response systems, and modified client systems on the user’s PC that can facilitate the changes without ever having to involve IT in the password reset process.

Implementation of a Password Self Service system alone can save an organization hundreds or even thousands of calls per month thus saving substantial dollars in operating costs.  Combine this solution with other identity related solutions and the savings can grow substantially higher.

If you have been contemplating the implementation of a Password Self Service system or perhaps need to extend an already existing solution, call Identity Automation today and we can help you find a cost effective, right sized solution to meet your needs.

Contact us for more information.

Identity Lifecycle Management is a function that occurs in all organizations but is usually a manual process at best.  Many organizations are being driven to implement processes to automatically curtail user access based on their role within the organization and to automatically revoke that access upon termination.

A great use-case for understanding the power of this technology is to consider what happens when Judy, a finance assistant, gets a new job in the sales department.  To perform her new job correctly Judy will need different access to some of the systems for which she is already a user.  She will also need to be added to some systems for which she is not currently a user.  In a traditional environment we find that Judy is granted the additional access that she requires to do her new job but seldom is the unneeded access taken away.  This creates a situation, over time, where users have too much access and is oftentimes the cause of failed audits.

Another scenario to consider is what happens when an employee is terminated.  Typically HR will notify IT that a person is no longer employed and IT will then take the necessary steps to manually remove users from their systems.  The problem with this approach is that users are inevitably missed.  There are many reasons for this such as inconsistent names, inconsistent user IDs, IT is too busy and the list goes on and on.  What this means in the real world is that the business is at increased risk because the account is still active and accessible.  With the account still active, that means the company will be hurt or even fail its audits because user accounts exist in an orphaned state.

So what does all of this mean to you?  If you are a person responsible for ensuring that your company is compliant with security and legislative requirements and you are looking for solutions to control and curtail access then contact us and we can help you design and implement a solution that will meet your needs.

When we meet with a customer, we first like to build a common ground with regards to nomenclature.  In the identity management field this is especially true because terms are used differently by different people/organizations.  We find this to be especially true with discussions around the topic of SSO (Single Sign-On).

What does SSO mean to you?  Does it mean you log in one time and never get challenged with an ID/Password again?  Does it mean you are always challenged for an ID/Password but they are the same across systems?  Or, does it mean you never need an ID/Password and instead you use physical or biometric authentication?  The reality is that there is no right or wrong answer to “What is SSO?”.  However, we do put our own terms to use and I thought I would share those.  Identity Automation sticks with two terms with regards to SSO: SSO (Single Sign-On) and RSO (Reduced Sign-On). 

The SSO term, for us, defines a euphoria where the end user logs in once to access their workstation.  This initial authentication could be an ID/Password challenge or some passwordless challenge such as using physical or biometric means of authentication.  Subsequent application access will not challenge the user for further authentication.  The challenge still exists but it is handled by some type of software layer that knows the user’s credentials and is populating them on behalf of the user.

The term RSO is significantly different.  The concept of RSO is that the number of ID/Password combinations an end user will need to remember is “reduced”.  In other words, the end user will need to authenticate to their workstation AND to each application; however, the ID/Password will be guaranteed to be the same on each challenge.  This scenario is also a euphoria in its own respect depending on the number of applications in the environment that require authentication.

Now, neither term or approach is considered “best practice” or the right answer.  There are use cases that make sense for both.  In fact, it is more common to see both SSO and RSO used in an organization than just one or the other.

There are many factors when determining which method(s) to use.  Just to name a few there are security, cost, and usability concerns.  To implement SSO, you must deploy an SSO product and “train” that product how to authenticate to each system in the environment.  For RSO, you must implement a combination of password synchronization and centralized authentication (e.g. LDAP) solutions.  Neither of these are “quick wins” but both have significant long term affects for the organization.

Currently, Identity Automation is working on a passwordless SSO solution through our partnerships with key technology providers.  The end result will be a solution that greatly simplifies the end user experience and provides the utmost security.  The solution will utilize biometric authentication to the workstation and then a combination of products to provide the SSO to the remaining systems that end users would access during that session.  The use of biometric authentication means no more remembering passwords, no sharing passwords and no password guessing.  Although hardware costs are significant, the ROI to the organization is typically realized in short order, especially when you take into account the intangible savings provided by the enhanced security.

For more information, please submit your contact information and one of our sales representatives will contact you.

Today’s enterprise is more complex than ever before.  The pressure on Information Technology departments to manage their technology resources to meet the current organizational needs all the while scaling to meet its future needs is tremendous.

Following are five areas that most businesses are challenged with today that would be significantly impacted in a positive way by implementing an Identity Management solution.

(1) Increased insider threats - Corporate crime and espionage cost businesses around the globe a total of $1.5 trillion each and every year.  A cornerstone in this battle is ensuring that employees and other staff only have the access that they need when they need it.  Ensuring that this is the case through automated means can significantly reduce the risks posed by these types of threats.

(2) Increased compliance mandates - SOX, HIPPA, Basel II and a litany of other regulatory requirements mean businesses must conform or run the risk of fines or even having their doors closed if they fail to comply.  Access control, separation of duties, zero-day termination and many other identity related factors are key to ensuring that these regulations are met.

(3) Increased Security mandates - Internal security departments are very aware of the risks that today’s enterprise faces and are taking ever greater steps to protect their data.  This means ensuring frequent password changes, implementing strong password policies, regular account and access attestation requirements and much much more.

(4) Downward pressure on staffing budgets - Enterprise information technology gets more complex with each passing year, yet IT staffing budgets never seem to keep up with the need for additional staff to manage the systems that run the business.  That means IT departments have to find ways to automate complex policies, processes and procedures so their staff can focus on more strategic needs.

(5) Increased pressure for resource productivity - Zero-day start has been the dream of IT departments for many years, yet it is rarely a reality.  Implementing role based provisioning and access systems can greatly reduce the time it takes to grant staff access to the systems they need on the day they need them, thus ensuring maximum productivity.

Identity Management is a complex area, but one that no organization should be without.  Whether your need is password synchronization, automated provisioning, workflow based provisioning and/or attestation, user password self service or any other identity related need, Identity Automation can help you find a cost effective, right sized solution.

Contact us for more information.

Today I read an article in NetworkWorld entitled “BYOD early adopters cite sticker shock”.  I have discussed BYOD with many of our customers and, personally, I can’t buy into it.  To explain, here is my take on BYOD, the good, the bad and the ugly.

The Good

• Lower capital budget
• Increase customer satisfaction

The reasons to support a BYOD policy are obvious.  There is no arguing these expected benefits.  If you users are bringing in their own devices, at their own cost, then that is a cost savings on the organization’s capital expenditure budget.  The reality I have found though is that the BYOD implementations are not meant to reduce the existing budget but rather to keep it from increasing.  The organizations are still buying workstations/laptops for their end-users but they are making the decision not to buy smartphones or tablets in addition to the workstations.

“Survey reveals BYOD goal is money savings, but two-thirds find none and one-quarter see costs rise more than 20%”—.”

End-users today expect to be able to use their smartphones and tablets for personal and work use.  Certain tasks, such as email and calendar, are a no-brainer.  Integration with email systems from outside the corporate network is nothing new.  Employers have long since embraced allowing access to email from the outside.  This access has progressed and the new desire is for end-users to access their applications, printers and files that only exist inside the corporate network.  Enabling this access for end-users via their own devices seemingly increases internal customer satisfaction… at least initially!  That satisfaction is soon diminished as end-users experience complicated configurations, performance degradation, incompatibility and other unforeseen factors.

The Bad

• Costs to reimburse employee data plans
• Increases number of Help Desk calls
• Increases IT Technician resolution times

Some companies, approximately 8%, are picking up the tab for data usage.  This, as we all know from our personal data plans, can be very costly.  When employees know they will get reimbursed they are also not motivated to sign up for the most cost-effective plans.

“One in 10 answering the survey said their companies had gone “fully BYOD” in allowing employees to use their own devices at work, and expected employees to pay all their monthly network service charges in full themselves, while another 8% practiced BYOD with reimbursement.”

As mentioned earlier, end-users quickly become frustrated when learning how to enable corporate services such as wireless, VPN, etc.  They also lack the proper clients for dealing with applications and files.  This results in net new Help Desk calls.  This also requires Help Desk staff to be savvy with multiple brands and OS’s since there is no limit to the diversity in a BYOD model.

“More than two-thirds (70%) answering the survey said they saw no change with BYOD, but 28% said costs increased by 20%. “By rights, users who bring their own devices to work shouldn’t automatically expect technical support from their IT staffs,” the report remarks. “On the other hand, what is the support staff supposed to say when users experiencing connectivity problems or performance degradation come calling?”...”

When calls get escalated to the IT Technician, this again causes *additional* overhead.  Similar to the Help Desk staff, the IT Technician is *expected* to be able to handle issues with devices owned by the end-user.  Organizations have learned over the years to buy hardware from the same vendors so that the costs associated with support are lowered.  Your IT staff become very familiar with what is in place.  Hardware configurations are usually made similar down to the same types of wireless adapters and video cards.  Again, this reduces the costs associated with troubleshooting device issues.  In a previous professional life, my organization was so standardized across our workstations that if you couldn’t resolve an issue within a few minutes you simply re-imaged the machine and the end-user is back up and working in a matter of minutes.  This is not the case when in a BYOD model.

“The IT staff is increasingly in a situation where they have to “do their best to support a multi-OS mobile environment, particularly since it’s not necessarily evident to the end-user whether the cause of problems lies in the device itself, the public cellular network or in the corporate network.”

The Ugly

• Increases internal security risks
• Requires significant infrastructure changes

“According to the survey, 52% said they have a written mobile usage policy that users must sign as part of the management process. Security is a top reason not to go into BYOD.”

A question we get almost daily is, “Can your software manage Live@edu and Google Apps accounts?” The short answer is - ABSOLUTELY!

With ARMS and DSS we can provide full identity lifecycle management for accounts in Google Apps, Live@edu and Office365. The most common approach is to connect to your systems of authority such as your Human Resource (HR) system or your Student Information System (SIS) and look for specific events such as new students, new staff, terminated students, terminated staff, name changes, location changes and any other changes that are relevant for your downstream systems.

Another common question is, “How can we keep our passwords in synch?” ARMS and DSS take care of this need as well. When a user changes their password, we can automatically push that password change to all of your connected systems to ensure that your users have a seamless login experience to all of their enterprise resources including cloud-based services such as Office365 and Google Apps.

If you are looking for a way to automate the management of your cloud-based services, whether it’s for 100 users or 200,000 users, give us a call and we can help you implement a solution to meet your specific needs.

At it’s core, Data Synchronization System (DSS) is a data management tool.  This tool helps us to tackle various use-cases, the most common being, Identity Management. In addition to IDM, we use DSS on a regular basis to build Enterprise Application Integration (EAI) Solutions as well as Extract, Transform and Load (ETL) Solutions. Another excellent use for DSS is in building Data Virtualization Solutions.

Simply put, “Data Virtualization describes the process of abstracting disparate data sources (databases, applications, file repositories, websites, data services vendors, etc.) through a single data access layer (which may be any of several data access mechanisms). This abstraction enables data access clients to target a single data access layer, serialization, format, structure, etc., rather than making each client tool handle multiples of any or all of these.”¹

Whether your applications are on-premise, in the cloud, or both, DSS can ease and automate access to your data via a meta-data construct thus enabling or facilitating the use of an organizations data in ways that are not otherwise possible for the purposes on data mining, reporting, validation, and much, much, more.

Contact Us today to find out how we can provide this solution for your organization.

Many of our customers are implementing or considering the implementation of hosted application services (aka SaaS).  The benefits are obvious because your support burden is reduced whether that be due to increased resource utilization, hardware savings, software savings or otherwise. 

For the sake of this article, let’s use the example of implementing hosted email services by Google.  Google Apps is a great solution for commercial, non-profit and public organizations.  The Google infrastructure is better than most organizations could provide themselves.  Your internal customers have 24/7 access to their email, calendar, docs and other services provided by the Google Apps offering.  As an IT department, you no longer maintain your email infrastructure.  You no longer have to keep internal resources trained on your email system and you can now take back those resources that were dedicated to supporting email and reassign them to other projects.  All of this is great and seems like a no-brainer for many organizations.

The truth is, you do still have some management burden.  Even though you don’t support a local email system, you still are responsible for setting up and managing your user accounts for Google Apps.  You will still get the call when users can’t access Google Apps because they don’t have an account, they are disabled or they don’t recall their password.  Many IT departments are disappointed to see the lack of tools available to automate this process.  Google does provide a directory synchronization tool but it isn’t perfect.  Password management is an all together different issue.  Although this isn’t the basis for this article, it is worth noting that Identity Automation has a Google Adapter for DSS the can fully automate the management of users and groups in Google.  This solution absolutely deals with much of the pain associated with managing Google Apps accounts, but I digress.  The point of this article is to specifically discuss passwords regarding hosted services.

Back to our Google Apps example, our adapter is capable of taking passwords from your internal directory service and synchronizing those to the matching Google Apps account.  This is a great solution but it can raise security concerns.  Google hosts their Google Apps in a high security facility.  Their employees are well vetted.  That doesn’t mean every hosted services provider goes through the same pains regarding security.  The alternative?  SAML!

Many hosted services providers support SAML for authentication.  Google Apps, Salesforce.com, Zendesk and Zoho to name a few.  A system that supports SAML as a means for authentication is referred to as a Service Provider (SP).  An SP requires the availability of an Identity Provider (IdP).  When a user accesses Google Apps (with SAML configured), they will not authenticate directly against the Google servers.  Instead the SP (Google in this case) will refer the user’s browser to the IdP.  Our ARMS and/or DSS products both act as an IdP.  The IdP is configured to authenticate users against your internal directory service such as Active Directory.  That means when a user accesses Google, to a redirected to your ARMS (or DSS) appliance where they will log in with their network credentials.  The same credentials they use to log into their office workstations.  Once authenticated, the IdP passes a secure token that tells the SP that you successfully authenticated and informs the SP who you are in its system.

SAML is important to your organization as you move more towards relying on hosted services.  Without SAML you are storing credentials in an untrusted environment.  You don’t always know how those credentials are stored and secured.  A user’s credentials in these systems likely match the same credentials used for in internal systems.  If the passwords in the hosted system are stored in an insecure fashion you’ve basically exposed access to internal systems as well.  With SAML, there is no credential stored in the hosted service providers facility.  There is zero risk of credentials being exposed and stolen.

By combining our Google Apps Adapter for DSS and ARMS with the SAML IdP service, you now have a viable option fully automating the management of accounts and providing secure SSO without the risk of storing user credentials “in the cloud”. 

Contact Us today to find out how we can provide this solution for your organization for Google Apps or other hosted services solutions.

Not a day goes by that we don’t have a conversation with a customer about some service they want to connect to that exists in the “cloud”.  There are numerous ways to handle the authentication for those services and there is increasing interest in the use of SAML for this purpose.

If you’re not familiar with SAML (Security Assertion Markup Language 2.0), it’s a “standard for exchanging authentication and authorization data between security domains. SAML 2.0 is an XML-based protocol that uses security tokens containing assertions to pass information about a principal (usually an end-user) between an identity provider and a web service. SAML 2.0 enables web-based authentication and authorization scenarios including single sign-on (SSO).” ¹

One of the big questions when considering the use of SAML is who are you going to trust to be your SAML provider?  As we hear of more security “incidents”, organizations that we talk to are questioning the wisdom of allowing someone else to host their credential data and are interested in being their own SAML provider. With the upcoming release of ARMS 2.1.0 you will now be able to be your own SAML provider and able to direct applications that can leverage SAML for authentication, such as Salesforce.com, Google Apps, Zendesk, etc, to your system for authentication.

If you want to learn how you can implement your own SAML Authentication Provider, please contact our Sales Team today!