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.
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.
User profile management should include the following functionality.
- Account management including lifecycle management
- Support for multiple identity providers (IdP)
- Login / Logout
- Single sign-on (OpenID, Facebook Connect)
- Profile management
- Authorization (Native, OAuth)
- ?
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.
No comments:
Post a Comment