I had a talk last week with an industry luminary who assured me that identity will eventually be all about "the attribute."

Today, I saw a story that characterizes what he was talking about, including additional issues surrounding privacy.

The Centers for Disease Control and Prevention (CDC) reported that it tracked the source of an 8-month-old salmonella outbreak across 44 states using data collected via customer loyalty cards shoppers swipe at the grocery store.

By using "attributes" from shoppers's cards, i.e what they purchased and when, the CDC was able to pinpoint a Rhode Island company that makes salami and then to eventually hone in on the pepper used to season the meat.

Adhering to Kim Cameron's Seven Laws of Identity, users agreed to reveal their information. Costco, one of many retailers that participated in the investigation, told MSNBC that it provided data to CDC, but only the data in question.

Christine Summers, the Issaquah, Wash., chain's director of food safety, told the news outlet, "They ask, 'Did this member purchase products A, B or C in this time frame?' and we tell them, 'Yes, they did' or 'No, they didn't.'"

The specific information also adhered to the Seven Laws of Identity with its disclosure focused only on the relevant data.

In typical use cases, attributes are used to acquire something for the end-user, i.e. access to data/services. But in this case, a collection of a certain attribute from many users was aggregated to create, in essence, another attribute that pointed the CDC in the right direction. The agency acknowledged that the data provided the break that it needed.

Clearly, attributes and collections of attributes are key to the information needed to support authentication and fine-grained authorization. For the enterprise, the backbone should form around SAML and XACML. OpenID, OAuth and OAuth Wrap are likely to play key roles on the consumer side.

The other issue here is clearly around privacy. But given that users agreed to share data/attributes those issues may be unfounded in this case. The questions, however, highlight that privacy is essential, especially in a case where the collector of the data was sharing it with a third-party.

Katherine Albrecht, the director of a group called Consumers Against Supermarket Privacy Invasion and Numbering, told MSNBC that she worries the practice could lead to a switch from a voluntary system to mandatory use of such cards.

"That sends chills down my spine," she said.

DENVER, Colo. -- Mar. 10, 2010 -- Ping Identity today announced open registration and a full lineup of sessions and speakers for the 2010 Cloud Identity Summit. Change leaders, visionaries, architects and business owners will converge at Colorado's Keystone Resort July 20-22, 2010, to forge a new era of cloud security via identity.

As the ecosystem develops in cloud computing, security emerges as the primary issue impeding widespread adoption. When companies evaluate the risks and opportunities, Internet identity surfaces as the central component for enabling secure access to services of the Cloud.

At the Cloud Identity Summit, industry leaders will share their thoughts and plans for identity and security in the Cloud. No other event will provide more insight into the converging worlds of identity management and cloud security as the Cloud Identity Summit. Join other change leaders in three full days of workshops, vision, architecture and implementation presentations as well as hands-on demos showcasing the standards, trends and the role of identity in securing and harnessing the Cloud.

Cloud Identity and Security Visionary Speakers:

* Cloud Security Alliance Executive Director Jim Reavis
* Google Security Product Manager Eric Sachs
* Microsoft Technology Fellow, Cloud Identity and Access, John Shewchuk
* PayPal Senior Director of Identity Services Andrew Nash
* SafeNet Chief Technology Officer Russell Dietz
* SuccessFactors Vice President of Cloud Computing Tom Fisher

Pre-conference Technology Workshops

* Cloud Security 101 with Arctec Group Managing Principal Gunnar Peterson
* Implementing SAML for SaaS Single Sign-On with Ping Identity Solutions Architect Ian Barnett
* Implementing OpenID & OAuth for Consumer Identity with Google's Open Web Advocate Chris Messina and Google's Social Web Engineer Joseph Smarr
* Implementing XAMCL & Authorization for Cloud Computing with Axiomatics Americas Division President Gerry Gebel

The Cloud Identity Summit is sponsored by Ping Identity and SafeNet. Visit www.cloudidentitysummit.com for more information and to register for the event.

Are you tracking identity, security and how those relate to cloud computing, securing your apps or integrating SaaS?

Any of these sound familiar or are they in your enterprise roadmap – OIDF, OIX, Oauth WRAP, XACML, WS-Federation, Shibboleth, OpenSAML or any number of other issues, workshops, etc.

If you are on Twitter or need a reason to check it out, I have put together a list of more than 40 identity technologists, analysts and experts who are dissecting the issues. Tune in here and join the conversation.

Earlier this week I discussed SAML and how it meets the requirements around TV Everywhere authentication.  While SAML 2.0 looks to be the de facto solution for solving the TV Everywhere authentication problem, there is still some debate as to what mechanisms and protocols will be used to address how authorization decisions are made by the MVPD’s on behalf of the programmers. XACML is the leading candidate, but XACML is only a starting point that defines the syntax for expressing an authorization query and an authorization response.

The first question is to define an appropriate back-channel protocol to convey the XACML authorization queries and responses between programmers and MVPD’s. This could be achieved via the XACML profile for SAML, or even via a simple REST API.

In addition a TV Everywhere specific taxonomy for authorization queries that programmers ask of MVPD’s needs to be defined. This taxonomy is dependent on the business rules that will be established for TV Everywhere. For example, if the user is trying to watch an R-rated program then the programmer needs to check with the MVPD before making the content available to the user.  The query could be one of ‘What is the users birth date?,  ‘Is the user over 18?’ or ‘Can this user watch Mature content?’.  

Another issue is that, unlike books and ISBN numbers, there is no globally unique identification system for programming content. Each MVPD and programmer has its own content classification and identification system. This becomes problematic if the MVPDs need to make authorization decisions based on the specific program each user is attempting to watch.  What do you do in federated authorization model where the object or resource (i.e. the program) is known by a different identifier at the programmer and the MVPD? Best case is to define an MVPD neutral identification scheme for all programming content.

The TV Everywhere industry is driving to have this all wrapped up by September 2010. It should be a fun ride participating in this effort and watching it all unfold. 

 Pam Dingle and I have been recently discussing the pros and cons of using enterprise password synchronization tools with SaaS & cloud applications. We are hoping that we can convince everyone that pushing Enterprise passwords into the cloud is a bad idea and in our opinion is certainly not a security ‘best practice’.

Synchronizing passwords inside an Enterprise is reasonably common if you have a provisioning engine.  It is the next best thing to SSO, reducing the burden on users memories if not reducing their typing burden.  If you can push passwords from a central location such as Active Directory, help desk calls are reduced because one password reset fixes a bunch of applications, authentication becomes more about muscle memory than actual memory, and IT departments can demonstrate some streamlining in their processes.

We think a lot of people will make a simple leap towards wanting the same efficiency and automation in the cloud - but to us, this is a mistake of epic proportions.  There are critical differences between pushing a password around inside a domain and pushing a password to different domains, and we personally believe that in the latter case, the ends do not justify the means, and instead expose an Enterprise to a cartload of risk.

• At the time you push a password to the cloud, it has to be translatable to clear text.  It may arrive in an encrypted message with all the security around it in the world, but once you strip the transport-layer or even message-layer security off, that password is accessible to the SaaS service.   You as the Enterprise have given it away.   Hopefully your passwords aren't being stored in clear text in a database somewhere.  Hopefully your passwords haven't been skimmed by a script on their way in.  Hopefully the SaaS service you've contracted with has good security practices and honest staff.

• For every SaaS service you push passwords to, you multiply the number of people who might not be so honest, or so security conscious.

• Every external login screen you teach your users to type their enterprise credentials in represents a new phishing opportunity for attackers.

• Most Active Directory password synch tools require installing a specific software module on every domain controller. This module is needed to intercept the password changes before the password is hashed/encrypted in AD. Installing third party software modules on AD is usually an AD support/ops headache.

And yes, for the detail-oriented in the crowd, you could theoretically share a secret between the enterprise and the SaaS provider so that both parties could do password validation.  If you care enough to do that, you'd be federating with SAML already.

That brings us to the human element: every external login screen you teach your users to type their enterprise credentials into represents a new phishing opportunity for attackers.  A new window where muscle memory takes over and your corporate credentials are compromised.

Lastly, this isn't just about stealing access to a cloud resource.  This could result in compromise of internal resources, through externally facing web applications.  Imagine somebody sells a cloud-synchronized password list to bad guys:  If you don't synchronize passwords, this password list could have a percentage of overlap, simply because your users independently use the same password.  Your security folks have  at least a chance to detect a problem, because there are going to be a suspicious number of failed logins for the percentage of employees whose passwords match.  If you do synchronize passwords, you have 100% overlap - the bad guys can authenticate correctly all the time, every time.  If all you are tracking is failed authentications and lockouts, you won't even know you're compromised.

We tell end users all the time that it is dangerous to use the same password in multiple places.  Any enterprise that institutionalizes this practice is taking a well-known critical mistake, and multiplying that error for every single employee that they take care of.

So what’s the alternative to synchronization? Obviously having your users maintain different passwords at every SaaS application is just ad bad an idea. This is why we think SaaS/Cloud SSO is the killer app for identity federation. Enabling SSO means that your users leverage  a single, centralized authentication service where additional security controls such as strengthening the login process with multi-factor strong authentication.can easily be incorporated.

Force.com has a unified security layer that underpins all applications across all customers. Users are a pivotal resource within the framework, and various configuration choices can be made to customize how these users exist and interact with platform resources. While developers may not have to write code around user management and access, they still must understand what the platform offers in order to best meet the needs of their customers. The general process of managing users and their domain of influence in a system is often called identity management.

Join Ping Identity's CTO Patrick Harding and Pam Dingle as they discuss (view entire article) identity management and SSO on the Force.com platform. The article explores user provisioning, authentication and authorization, and points at the more advanced sign-on features such as SAML.

Introduction

The identity and access tools supplied by the Force.com platform are sophisticated enough to allow a developer or architect to completely automate user provisioning, for example by linking creation of platform users to the addition of an employee to a group in a corporate Active Directory deployment, or to implement Single Sign-on, a configuration where user authentication to Force.com is taken care of for the user, resulting in transparent access from a corporate Intranet to the platform.

This article provides an overview of the identity management features that are provided out of the box on the Force.com platform. The three basic concepts described in this article are:

• User provisioning, or how user profiles are created and changed over time. Authentication, or how users are identified and their identities validated.

• Authorization, or how users are granted permission to specific resources.

Use of the web-based administration console, use of the Force.com Web Services API, and use of Internet standards are all discussed, and impact to developers of each choice are discussed.

Read entire article...

We announced a key capability in PingConnect™ today - Google Enterprise users can now leverage their Google Apps login to seamlessly access over 60 SaaS applications via PingConnect. 

So what’s the big deal and why should you care?

Our vision is that employees of all organizations (small, medium and large) should be able to seamlessly access the SaaS applications they need to do their job from anywhere, on any device, from any starting point. They should have this flexibility without needing to remember a litany of additional user passwords.

As such in PingConnect we started by providing support for the Windows Active Directory password.   This was a fairly simple choice, considering that the Windows password is a very common authentication credential that employees use when they are at work.  Note how I said ‘at work.’ 

What about when your employees are on the road, or start their day by logging into one of the Google Enterprise Apps such as Calendar or Sites, or your organization does not use or is migrating away from Active Directory, or all of the above?  What are your alternatives when the user cannot leverage or does not have a Windows password? 

We have no aspirations for PingConnect to be ‘yet another’ authentication service to solve this problem. The last thing our customers want or need is another PingConnect specific credential to remember and manage.  Further, Ping does not want to be in the business of user registration, identity vetting, password reset management, password security polices, etc. etc.  We have partners like Google who already do this extremely well.

This is why we decided that it made sense to leverage your Google login to access all of your SaaS applications.

But we aren’t stopping with Google. We have support for additional authentication sources in the pipeline and will be launching them soon.
 

Two of our customers have deployed PingFederate in the cloud on Amazon Web Services EC2. Here are the steps they used to deploy on AWS.

Setting up PingFederate 6.0 in AWS was a pretty simple affair, I'm using one of the public Ubuntu 32-bit instances for testing and followed the installation recipe fairly closely, just adapting it in places so that it fit with our deployment strategies. It is still a work in progress but if you are looking to implement a paid/public AMI with PingFed it should be a pretty cut and dry affair.

• Setup pingfed user
• Install JDK 1.6
• Setup JAVA_HOME path for JDK
• Unzip PingFederate 6.0

Adapt init script to point at the pingfed directory and use the pingfed account. At the moment, I have it running on the stock port but will likely change that to use 443 when we go to production as these servers will likely be standalone instances.

We met with a large systems integrator recently who has deployed a federation lab to build a center of excellence and competency within their practice around identity federation.

PingFederate was the only product to complete all tests. The nearest competing product finishing around 20-25% at most.

This is what 7 years of focus, passion and a lot of persistence results in.