1

I implemented SSO for my web applications with following architecture enter image description here

These are basic flows: enter image description here

Now conceptually it seems OK to me but what bothers me is the fact that all applications depend on SSO web api.

  1. if something changes in SSO Web Api, all applications could suddenly stop working - what is good approach of versioning Web API to make it backward compatible?
  2. If SSO API has DTO objects for users (username, email, roles, functions) that means I have to share them somehow with App1 and App2. I considered SOAP with wsdl but I would like to stick with Web API since its much more flexible client-wise and successor to WCF. One thing that comes to my mind is putting DTO objects of SSO API into separate class library project and referencing it in both App1 and App2?

EDIT: I need this for intranet applications with role/function based authorization

Pavle Gartner
  • 659
  • 1
  • 7
  • 21

2 Answers2

2

Regarding your two questions: There are well established standards for use cases like yours. Have a look at OpenID Connect and OAuth or the older, more enterprise-like, WS-Federation/SAML.

Anyways, rolling your own security is usually no good idea and a thing you should avoid (evidence). For a quite ready-to-use solution have a look at IdentityServer.

Jan Köhler
  • 5,817
  • 5
  • 26
  • 35
  • I did check out OAuth but it is confusing to me (it seems more about authorization and not classic role based, but letting the user to control how their resources may be accessed by third-parties - which is not what I need). So to use library that is built on top of OAuth and does support SSO, well it seems a bit of overkill if I only need centralized authentication and basic role based authorization? – Pavle Gartner Apr 24 '16 at 07:16
1

This looks like a home-grown SSO solution. I recommend that you don't build your own.

On the other hand, to answer your questions:

Q1: You have to version your API. There are several ways to version it. The easiest probably is to have a version number in your routing like: "api/v2/sso"

Q2. If you have a DTO, you can create a library project that only contains the DTO. You can share the library by hard-referencing it as a DLL in your App1 and App2 project or you can distribute it as a nuget package. I prefer the nuget package - you can have a nuget server that is web based(hosted in IIS) or as a shared drive in your network.

alltej
  • 6,787
  • 10
  • 46
  • 87
  • Thanks for answering my 2 questions NuGet server seems like very interesting idea. How should it be managed if project are source controlled, e.g. git? About SSO - any recommendations? – Pavle Gartner Apr 24 '16 at 07:13