Trying to look at building an SSO using C#

davetherave2

davetherave2

davetherave2

Soldato
Joined
27 Mar 2003
Posts
2,710
So I am in the middle of learning a hundred and one things (exciting times)
but as part of my work/ personal projects I want to build a centralised user admin section that I can use as an SSO portal (think Google here)

Now I am working in the C# MVC 5 world and loving everything I have learnt so far, but I am just trying to move away from having to do a lot of copy paste code for the apps when it comes to Authentication/Authorization. I am moving more to the "Claims" world for all my access rights etc.

So I have picked up a lot of information but I haven't really seen any good articles/ walkthroughs on how to go about setting one up.

Now I have trying to build something using ws-Fed but have hit a wall with that and although I have my application redirecting to my login server and it authenticating the user, on the redirect back to the original app the cookie being set on the login server is not being persisted across. So I am clearly doing something wrong.

Is ws-Fed the right technology to use or should I be looking at something else as I want this to work for both MVC/WebApi calls.

Any advice would be greatly received.

(I know doing this will not be a simple task. But I hope to put a blog together documenting my journey so that others may find it useful in the future)
 
I had a brief look at it. I have used Brock's Membership Reboot in past projects.

As a topic there seems to be lots of fragments of info about this but not an end to end detailed description on how to plumb one together. Hence my interest in this.

I think it may be something that I look at using in the mean time with the idea of building my own later.

I know that Brock is looking to possibly do a SCIM project which again sounds interesting.

After looking at a lot of security based stuff recently I have got a bit of a security kick going on.

I am looking for cross domain authentication within my environment so is ws-fed the best mechanism to use or would something else be better?
 
"cross domain authentication" is claims-based auth by it's very definition

ws-fed is just a protocol which ties together the interaction of auth systems & actors

not really sure what you're asking IMO - it sounds like you don't have a grasp of the principles
 
This I think is where my problem lays with all this sso stuff. I have watched a couple of pluralsight courses and read so much stuff it has mashed up my brain and got me more confused than anything.

Essentially what I am trying to do is the following

MVC Sites
App1 (lets call it www.elitedomain.com)
App2 (lets call it www.normaldomain.com)
App3 (lets call it client1.normaldomain.com)


REST Services

App4 (lets call it service.elitedomain.com)

..... (Well you get the idea)


What I want them to do is go to the following app (sso.mysignindomain.com) if they have not been authenticated on any of the apps.

Once the user has been authenticated and returned to the original site they tried to access, if they are authorized to view that site then they can access it and work happily otherwise they get sent to a friendly access denied message.

By doing this I am then hoping I can manage all access rights/roles centrally and delegate all the authorisation to the sso system.

Also gives the user the ability to manage their profile in a central place and have a consistent experience for them.

Hopefully this explains a bit better what I am after.
 
ThinkTecture Identity Server is exactly what you need here - the identity server is your sso.mysignindomain.com auth server which acts as STS and IdP (google these terms) for your other web apps

You can integrate your MVC web apps with the identity server using Windows Identity Foundation features in .NET 4.5 - the identity server exposes a WS-Fed metadata endpoint that your MVC apps can consume in order to configure themselves to authenticate with it - you will need to configure your web apps within identity server so the identity server is able to recognise them (redirect uris, etc) - there are plenty of tutorials around for this but yes, I agree it is all very complex and there are many acronyms to learn. SSO is managed between your web apps by claims given out by the identity server stored in the browser cookie (high level view, but you get the idea)

You can configure user accounts & profiles in identity server - restyle it all so it actually looks like part of your app(s) if you want to etc. it's very customisable

http://goo.gl/yKtK2J
http://goo.gl/yA4Sgx

http://goo.gl/6wghM6

there is lots of info about as it's quite well regarded as a production quality (open source) auth & identity solution

for your web api application, I'd use OAuth2 (identity server can also act as your authorisation server as it is able to speak OAuth2) - inbound requests to your web api should require an OAuth2 bearer token in the Authorization header (you can, when you receive a token, check it's valid by passing it over to identity server I think - where it should have first been issued from)

http://vimeo.com/43603474
 
Thanks for the info robot.

I am taking a little break from the SSO stuff for the time being to finish building my application and then will look at this again with a fresh perspective in a month or so.

I think I will need that much time just to let everything sink into my brain.

I think it is probably time to go back to basics with this and start from the very beginning again and step through until I understand the concepts a bit more before jumping in.

Again thanks for the advice and I will update this thread once I have taken some time to develop my ideas.
 
You must log in or register to reply here.
Back
Top Bottom