would you use webfinger?

I was at the Internet Identity Workshop #10 today. I have been to an unconference only once before. It looked like a chaos initially but it was organized chaos. I liked the format. Moreover, I liked how open the participation was both from the presenter and the listeners.

Anyway, while I was slightly familiar with OpenID and OAuth, I am just getting familiar with some of the problems of the initial versions of the Open ID and OAuth 1.0a. Came across several initiatives ... one of which is WebFinger.

"WebFinger is about making email addresses more
valuable, by letting people attach public metadata to them. That
metadata might include:

• public profile data
• pointer to identity provider (e.g. OpenID server)
• a public key
• other services used by that email address (e.g. Flickr, Picasa, Smugmug, Twitter, Facebook, and usernames for each)
• a URL to an avatar
• profile data (nickname, full name, etc)
• whether
  the email address is also a JID, or explicitly declare that it's NOT an
  email, and ONLY a JID, or any combination to disambiguate all the
  addresses that look like something@somewhere.com
• or even a public declaration that the email address doesn't have public metadata,
  but has a pointer to an endpoint that, provided authentication, will
  tell you some protected metadata, depending on who you authenticate as."
  

Eran Hammer-Lahav describes the rationale for the same over here. I like number of arguments he makes, however, I am stuck on the following ...

"The arguments against email as identifiers usually include concerns
over spam and privacy ..."

At least with the Http URI, I don't have to worry about spam. Indeed, there is a phishing problem, but as far as one knows how to protect against it, it might be manageable. How do I know that the email address I am giving to some site in order to enable it to fetch my public meta data won't be misused? Am I missing something here?

User profile management in a social application

In my opinion, user profile management is one of the most important aspects of any social application. Social graphs are made of people and relationships between people. Not only the user profile allows an application developer to capture the information about a person, it is also an important dimension in deducting various kinds of user and usage focused analytics. Such analytics is very important for a social application. If designed well, it could also help increase the application's user base. I will explain about this further later.

User profile management should include the following functionality.

1. Account management including lifecycle management
   
2. Support for multiple identity providers (IdP)
3. Login / Logout
4. Single sign-on (OpenID, Facebook Connect)
5. Profile management
6. Authorization (Native, OAuth)
7. ?
   

Account management
From an application developer's perspective, every user of the application must have an account regardless of how the user logs in (user/password, OpenId or Facebook auth). An account could have minimal information such as display name, email, status, timestamps for creation and modification times. Account may not necessarily have user's profile information.

The lifecycle events associated with an account could be registration, activation, deactivation and finally deletion.

Support multiple IdP
Any social application should support at least 3 types of identity providers in my opinion. A local IdP, OpenID IdP and Facebook.

The local IdP comes handy when potential users of the application do not have any OpenID or do want to create and maintain a profile with the application. The local IdP is usually implemented as identifying users with username and password. Database is generally used as a realm.

The application should also support one or more OpenID IdPs. Many users may not want to create one more online identity to login to the application. They may want to use one of their existing identities managed by a 3rd party identity provider (Yahoo!, Google, myOpenId, etc.) using the OpenID protocol. An application would act as a relying party (RP) that relies on identities asserted by the 3rd party IdPs.

Lastly, any social application developer may want to tap into Facebook's 400MM user base. Unfortunately, Facebook does not support open standard such as OpenID. So, the application has to support proprietary FB authentication protocol (FB Connect).  

See Stackoverflow or Plaxo login screens to check how these applications support multiple IdPs.

Login / Logout
This is a an obvious feature of any web application that would want to offer personalized services. No need to describe anything here except that a user should be able to login using an id managed by the local IdP or by a foreign IdP after due assertion of that id. Other functions would include ability to reset password (for local IdP only), "remember me" among other things. Session management (session expiration, persistent session, etc.) would be required as well as protection against session fixation attacks.

Logout for a user logged in using OpenID or FB Connect would require logging out locally from the application and destroying session context related to the application that is relevant to the user logging out. Note that for a social application, the short comings of a log out feature would not only expose the user but the user's social activities and social graph as well.  

Single sign-on
For a social application, user experience is very important. Offering single sign on could improve user experience right away. If the application user has logged into some other web application using OpenID or FB Connect, that user may not have to sign in again to your application (within the timeframe set by the OpenID IdP or FB) if you support OpenID or FB. Again, check out Stackoverflow or Plaxo.

Profile management

The profile data of a user is important for any social application as
it acts as a very important dimension in various analytical services
the application could provide to the users, insights to improve its own
services and to interested 3rd parties. Account may hold minimal information about the user. An application may have a user profile to hold other user-specific information. This depends on the application but it could include information such as first and last name, nick name, address(s) (land and web), land and mobile phone(s), email(s), instant messenger id(s) and other demographics information as required by your application.

If the user logs in using OpenID, it is possible to populate some of these using OpenID's attribute exchange protocol at the time of login. FB Connect also has APIs to retrieve FB user's profile data per user's privacy settings. Such data could also be retrieved securely with user's consent after the login using the OAuth protocol.

Authorization
Authorization deserves its own post. I will cover authorization in my subsequent post.

If you are using a Java based platform on the server side of your application, you may want to look at Apache Shiro based Nimble project. Nimble is a Grails plugin that uses Shiro underneath. It provides most of the features I have mentioned here except OAuth. It also provides customizable user interface and security tags to insert into the user interface.

Social identity theft - protecting your personal brand

I recently attended a talk given by an OpenId foundation member. I would not say here where and who gave the talk. What I came to know is that the big web-based identity providers (IdP) such as Google and Yahoo! have embraced OpenId for almost couple of years now and they would want you to use your id/account as many places where open id is supported. Facebook wants you to do the same but their protocol is very proprietary. Anyway, this is good news!

1. This helps a lot in increasing user registration at a relying party (a social media application) web site because users can sign in using their OpenId. 
2. It also helps those folks who want to use OpenId to sign in where ever they could because they don't want to keep track of and maintain various social identities and profiles at various social media web sites. 
3. Lastly it helps in further service authorization and sharing of content using OAuth.

However, this also makes these folks vulnerable to social identity theft. If your social identity is stolen, not only you are vulnerable but your social graph might be vulnerable too (without any reason). This is more dangerous.
I came across an article "How to Combat Social Identity Theft and Strengthen Your Online Personal Brand" where the author recommends creating a separate profile and identity at each social media site . This is like having a separate password for each web site...hard to remember and maintain but it restricts the vulnerability to a single profile/identity/website if stolen. Some folks even provide a service to manually go and create profiles in your name at some 150 web sites! Indeed, what guarantee they give that they won't misuse this information, disgrunted employees could be found everywhere right! And finally there are tools like KnowEm which automate the process by helping find availability of the username at>350 websites and also help create profiles (with subscription service). Many other such tools are listed here.

I would think that one should carefully use identities maintained by the big guys. I would also keep more than one OpenId handy to use at various social media web sites so if any one of these is stolen, at least the vulnerability is contained to only those sites where it was used. However, indeed there could be a better solution...looking forward to your comments, thoughts and suggestions.

Relationship management in RESTful web services - Part I

CollectionSpace offers various RESTful web services for managing meta data for physical/digital objects. Defining RESTful interfaces for various entities in the system is straight forward. Create, Read, Update, Delete, List and Search (CRUDLS) operations on these entities could be easily be mapped to the POST (create), GET (read, list and search), PUT (update) and DELETE (delete) methods of HTTP. For example, see the RESTful APIs for the Role service.

CollectionSpace also has a requirement to support relationships between several entities. For example, there could be one to many relationship between a collection object and a loan object. On a more domain-agnostic side of the services, a permission might be for one or more roles and a role might be related to one or more permissions. Implementing relationships between the RESTful resources is not so straight forward and might need some due diligence. Let's take each of the above two use cases to model relationships in two different ways and talk about pros and cons of each. The two approaches are :

1. Relationship as a first-class RESTful resource
2. Relationship as a sub-resource

I'll cover only the first part in this entry. Feel free to comment on the blog if you have implemented relationships in different and better way.

Relationship as a first-class RESTful resource With this approach, relationship becomes a RESTful resource that supports CRUDLS operations. It is a bit unintuitive to think about relationships like this but it is the most flexible approach. Here, each relationship meta data has the following components:

• Object of the relationship
• Subject of the relationship
• Type of the relationship

For example, a relationship between a collection object entity and a loan entity in English could be:

The object in the relationship is the collection object entity and the subject of the relationship is the loan entity. The types should be namespace qualified. This is derived from the RDF model but perhaps only in parts. The relationship web service would support the following methods :

The advantage of such a data structure is that one can relate anything to anything without worrying about semantics. It is also the biggest disadvantage. Relationship being a first-class RESTful resource, each relationship has a distinct id of its own using which it could be retrieved and updated. However, there are many problems.

1. Unlike the RDF model, the predicate is missing, so it is hard to machine learn how entities are related. The web service would have to do a lot of validation to make sure semantically the relationships are possible between the given entities and are correct.
2. It is not possible to determine cardinality in the relationship
3. If RESTful URIs are used, there is no need to provide separate type and id. For example, http://collectionspace.org/services/collectionobjects/814ed9d4-3315-44fc-993b would uniquely identify the object in this relationship.

I'll cover the 2nd approach in my subsequent blog entry.

Account/user management live in CollectionSpace

I am glad to see the Account service having a face on the CollectionSpace UI. Thanks to the TorontoU and the CambridgeU (UK) teams for pulling this off. It is available in the upcoming 0.6 release to play with at a test server. Eventually it will be moving to the demo. The project release documentation has a nice walk through with screenshots.

RESTful management interfaces for security services

In the past, I used WebLogic Security extensively while at BEA. We were building security in the "layered" products : WebLogic Integration and AquaLogic Service Bus. The runtime APIs at our disposal were the Java APIs weblogic.security.* and for management the JMX APIs in weblogic.management.security.*. The JMX APIs are remotable, indeed behind the firewall, but remotable.

Indeed, we had to build security console using JSP/JSF/Struts/etc. so the security administrators of these products could manage users, accounts, roles, user-role mappings, permissions/policies, keys and certificates, etc. The console implementation would use JMX APIs underneath. Alternately, application developers could build their own administration consoles by directly using the JMX APIs behind the firewall.

In the open source, there are good options available for enterprise security such as Spring Security and Apache Shiro. These have non-remotable management APIs in Java. However, I could not find any remotable management interfaces that could be easily accessed from a web-based console over HTTP. So, for CollectionSpace, we built management interfaces using REST. These include

3 entity resources

1. Account (also manages a simple IdP using DB realm)
2. Role 
3. Permission 

and 2 relationship resources

1. AccountRole a sub resource accessed from the account service
2. PermissionRole a sub resource accessed from the permission service

Your feedback

If you think these management interfaces would be useful in other projects or if you have suggestions, please send me an email at [sanjay dot dalal at gmail dot com]. We could perhaps extract these out from CollectionSpace and make them available through a separate open source project with Apache 2 license.

Authorization service RESTful interface

Yesterday, I checked in the last piece of functionality to complete the first pass at the RESTful interface of the authorization service in CollectionSpace. There is a short description of these APIs on the wiki. Yes, I am aware of the confusion behind the term authorization. I have described the terms used on the wiki.

1. Role
2. Permission
3. Role - Permission relationship (available from Permission service, /permissions/{id}/permroles)
4. Account - Role relationship (available from Account service, /accounts/{i}/accountroles)

Indeed, there is a separate web service for account management with its own RESTful interface. The CollectionSpace security runtime exposes APIs to enforce access control from the CollectionSpace services runtime and SPIs to plug in various providers. I will be using Spring Security ACLs as the underlying service provider.

More on the enforcement of the permissions in future entries. I will also write more about my experiences and approaches I took in implementing relationships between RESTful resources, e.g. relationship between Role and Permission.