Home » discuss » Public forums » Developing for iMIS

Using OAuth with iMIS - Logon with Facebook or twitter

Posted September 16th, 2011 by jhull-jurkovic
| | |

I have been asked by an AE whether it would be possible for us to create a custom login page for iMIS that allowed users to login to iMIS using either their Facebook, google or twitter credentials, 

All these apps now use OAuth 2 - which I have been reading about here developers.facebook.com/docs/authentication/.  and here oauth.net/2/

I know that normally we like to do things the other way around - make the CRM system the master login, and then pass an authentication cookie out to whatever sites. What we are trying to achieve is to make it easier for people to login to an iMIS website and make transactions or create content etc... So, if a user, for example sees an event promoted by a friend on facebook, they can click on the event link and just sign up for the event, without having to log in to iMIS. This would require us to work the other way around to how we like to . Facebook does the authorisation and passes that over to iMIS which logs the user in.

I wanted to ask some developer types whether it is feasible for us to create a custom iPart that would allow us to do this. My concerns regards this are:-

  • How do we link a specific iMIS account to a specific facebook account? When I log in to (say) FlickR with my google account, it creates a new FlickR account for me under that google login, and there seems to be no way to link my current FlickR account with my Google login. This would be disastrous in iMIS.
  • How do we stop the creation of duplicates when new accounts are created off (eg) Facebook (see above)?
  • What happens if we have disabled the person's login in iMIS (eg if they didn't pay their membership fees), but they can authenticate against facebook successfully?
  • What are the security implications? If someone's twitter account gets hacked, could this expose iMIS data?
‹ Modified Control for Impersonation reset without redirect in Roster ManagementProcess 1 payment for multiple event registrations in iBO ›
login or register to post comments | printer friendly version

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Also interested

On September 16th, 2011 Bruce Wilson says:

I'm also interested in this.  I'm 3/4 of the way through a project to provide single-sign-on between eCM and several other client sites using Shibboleth.  While all login screens live on the Shibboleth server, Shibboleth validates against the iMIS 15 logins (aspnet_Users et al).

Shibboleth allows users to be authenticated (prove who they are) using any one of multiple providers.  For this client, iMIS is the only source.  Once Shibboleth knows who the person is, the identification (what do we know about you?) and authorization (what can you access?) can draw from multiple sources at the same time (e.g. membership status from iMIS, community selections from Drupal, exam registration status from Experient).

As part of this research, I learned a bit about how iMIS authenticates and how ASP.NET security works.  iMIS uses a custom Membership Provider, which covers authentication and authorization.  (Note: then they built a web service around this called MembershipWebService.)  It should be possible to configure IIS to use a completely different custom Membership Provider -- one which asks how they want to log in (iMIS vs. OAuth2).  If they choose a different login source, then once the identity is known, the existing MembershipWebService takes care of the basic identity information.  If they choose iMIS, then the new custom Membership Provider would call on ASI's.

It may also be that you could just tell iMIS to use OAuth for all authentication.  This would be unsupportable by ASI Tech Support, but then most SSO solutions worth talking about cause the same problems.

This is all theoretical.  I would expect a custom membership provider to be something that takes effort measured in weeks or months, not days.
--
Bruce Wilson
Director, Technical Services
RSM McGladrey, Inc.

login or register to post comments

I have done this for a

On September 16th, 2011 james_schwartz says:

I have done this for a LinkedIn iPart I developed a couple months ago (which also uses OAuth).

Basically what happens is when the user opens the iMIS web page with the iPart, they will get prompted to allow LinkedIn (or Facebook or Twitter) to "trust" the application (the iPart). If they already have a LinkedIn account and they are already logged in, then they just have to click "trust" and it will create a token that the iPart can use to retrieve information from LinkedIn (or FB or Twitter). You don't necessarily need to store anything in iMIS about the user's Facebook/Twitter/LinkedIn account. If the user isn't logged in to LinkedIn, they can either create a LinkedIn account or login with an existing account (but they would still need to "trust" the iPart).

If they decide to use a different Twitter account in the future for example, they could simply log out of the existing Twitter account, login with their other Twitter account and again "trust" the iPart. It will then display relevant information in the iPart.

You don't have to expose any iMIS information in LinkedIn/Facebook/Twitter, and you don't necessarily need to pull any information from LinkedIn/Twitter/Facebook and store it in iMIS. You have full control in your code as to what you decide to do with the data that is available as a result of the user trusting your app.

Does that help? I can go into more detail if you'd like. I could probably even quickly set up a small sample app so you could see how it works.

I also developed a simple Twitter web part that doesn't use OAuth. It simply calls a web service to retrieve all of the twitter posts for a particular account and displays them in an iMIS iPart. As long as you aren't retrieving secure data from the Twitter account you won't need to do the OAuth authentication.

Cheers,

James / Bursting Silver

login or register to post comments