0

A client has a website that is using .net 4.0 with MVC. This website has its own database and identity tables.

We implemented a web application for the client that is completely decoupled from the website and its database. The applications database holds session information of what the user did along with many other this linked to the user. The users interacts with a Web API to manipulate data and those actions are audited and mapped to the sessions which the administrator can run reports on. This all works fine when the users are registered through the application itself and have their own login page which is how it was implemented at first.

The problem is that now the client wants to have Single Sign On using the website login page. The client wants the login page removed from the application and allow every current and future user of the website to have access the web application.

-What I know so far

  • Every user logging in through the website will have the Basic User Role in the application
  • The accounts that will have the Admin Role and Super Admin Role will be generated when the database is generated

My question is:

Is it possible to implement single sign on with two separate databases having their own identity tables? If it isn't what would be the best possible route to go since the application itself has its own authorization in place based on the specific users role and these users have been extended in the applications database. If it is possible what is the best way to get the existing users into the applications database if they aren't already in there.

Any help to point me in the right direction is appreciated.

Thank you,

jkerb
  • 179
  • 5
  • 1
    Something like this should do the trick. http://stackoverflow.com/questions/26309792/asp-net-identity-in-microservice-architecture/26310977#26310977 Share the authentication across multiple sites. – Brendan Green Nov 12 '15 at 20:45
  • First you have to trust (identify) the sending application as trusted. Next you have to pass the required attributes, roles, identity information to the receiving application. Check this out: http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/ – lcryder Nov 17 '15 at 18:17

1 Answers1

0

So you have 3 tasks to solve:

  1. How to map existing users of your application to the identities available on the Identity Provider (the other "main" application). Is preservation necessary at all?
  2. How to implement SSO (Login) between the applications.
  3. How to provision users in the future.

Mapping existing users to the identities on the Identity Provider might be very easy or quite complicated, depending on the situation. Can you uniquely identify users on some common info available on both sides, like email address? Are all users on your side also available on Identity Provider side?

SSO solution may vary from a primitive shared-cookie one to a full-blown OpenID Connect server. Is anything already in place for the SSO solution? Do you plan to connect further applications in the future?

Range or user provisioning solutions is wide as well: From giving RO access for your application to the DB of Identity Provider up to fault-tolerant solutions based on message-queues.

Vilmantas Baranauskas
  • 6,596
  • 3
  • 38
  • 50
  • 1. The website is using asp.net identity and so is my application. So the tables are exactly the same except for some extended attributes on my side. 2. All users on my side will eventually be the same as the ones on the identity provider side. I will have to clear all the existing users from my application and somehow add the users from the website into our application. 3. No other applications are going to have to connect via SSO – jkerb Nov 13 '15 at 14:20