we are trying to implement single sign on, across multiple domains, but using the same web application under IIS. We have checked some solutions like SAML and OAuth however we are not sure we need anyone of these two. We dont know how we could share the cookie accross the domains, I dont think it's possible but correct me if I'm wrong.
We have looked at google's solution when you go to youtube and you are authenticated with your google account it pulls out your username and your info, but we have no idea how they do this, because it's another domain so the cookie should not travel to youtube. If you have any suggestions on how to do this they more than welcome.
You may take a look at the following blog post in which Jeff Atwood explains the mechanism used by the StackExchange network to support cross domain single-sign-on relying on HTML5 Local Storage. And here are some more technical details.
Related
My company is wanting to implement OpenID Connect via Oauth 2.0 across our client software, which comes in Windows, HTML5, Android, IOS, etc. Toward that end, we are trying to find a way of getting the login info back that will work across these platforms.
Our understanding was that a custom uri scheme (i.e., companyname://) was the recommended way of going forward, and we have verified on our end that that would work. However, we have yet to be able to find a provider that would support that configuration. So far OneLogin & Google are both locked to https:// (or http:// for dev), which leaves us something of a conundrum.
So essentially, my question is, were we misled about the custom uri scheme? If so, is there another method we can use that will allow our web & standalone apps to pick up the return info from whichever OpenID providers we go with? We want to keep it open as possible, so we're trying to avoid lock-in APIs and suchlike. Any advice would be appreciated. Thanks.
We do support the custom URI redirect. You'll need to select right type of client when creating a client id on Google developer console.
See the details here.
https://developers.google.com/identity/protocols/OAuth2InstalledApp
One way to support any provider is that you use a Web flow to redirect to a page on your site and then your website does a redirect to a custom scheme.
More specifically, I mean being able to provide an OAuth2 service.
I've seen multiple websites used "Sign in with Twitter" "Sign in with Google" etc.. on their websites. I'm wondering if there's a certain process you need to go through in order to allow other websites to use your websites to authenticate.
Let's say I've got a website called "SomeRandomSite", and people can sign up/sign into this site as they normally would, but then if you go to some other website you'd see a "Sign in using SomeRandomSite".
When looking into it, I came across this article here:
http://scottksmith.com/blog/2014/07/02/beer-locker-building-a-restful-api-with-node-oauth2-server/
I have yet to finish reading all of it, but so far it seems like it's only allowing your application to incorporate other OAuth services such as Google, rather than building your own.
I hope I explained this well enough haha.
Implement OpenID Connect if you want to make your server behave as an Identity Provider (IdP). You can find a list of implementations of OpenID Connect in "Libraries, Products and Tools" page.
It basically means you want to act as an IdentityProvider, take a look at ThinkTecture.
https://identityserver.github.io/Documentation/
It's cetainly possible, but an Identity provider is usually a well known(trusted) party, between the IdentityProvider and the target site the user want's to log into there should be a trusted relationship, in other words the target site should register with you the IdentityProvider
Getting started example
https://identityserver.github.io/Documentation/docsv2/overview/simplestOAuth.html
I am developing MVC application and want to use WIF & Claim based security.
However I am very disappointed with the way login is perfomed. I mean redirection to STS login page and then redirecting back to my page. That is not user-friendly at all.
I want to implement login page in my application (it fact it will be popup dialog). Than using Web API I want to be able to perform STS request and get security token and initialize WIF infrastructure (Principle etc).
Is it a good way to go with?
Did anybody do something similar?
Does anybody have some samples of what I am trying to do?
I just worry that I don't have control over the STS login page layout & style.
Also I will have mobile application and must perform login using Web API service.
What can you advice?
Thanks
Well - you can do that of course. This does not need to be WIF specific. Call a service, pass credentials - and when OK set the login cookie.
But if you want SSO you have to make a user agent roundtrip to the STS - otherwise you cannot establish a logon session.
Consider using MembershipReboot membership provider which uses claims-based security and is not based on microsoft's traditional membership provider.
It does not have a documentation, but in the zip file you can find 2 sample projects that uses MemebershipReboot provider, which explains all you need to know about it.
In fact after reading this blog post today, I decided to use this approach in my current project. I'm still struggling with it now and I'm so excited !
In addition to Ashkan's recommendation Brock Allen provides solid documentation about how to implement MembershipReboot in association with IdentityServer. You can find that their is a way to configure a custom implementation Here. Also their are a few tutorials on vimeo from Dominick Baier (leastprivilege) that will provide a full walk through on getting started! I hope this helps!
I need to add social media login capabilities to a site and got stuck a bit, mostly because of the, more or less, non existing beginner documentation regarding these two.
I grasped the basics of DotNetOpenAuth by checking nerddinner but some here suggest WIF so I started looking into it. I realized quickly that just getting clear info explaining if this is feasible at all on shared hosting was not easy. I don't really want to pump through all reference knowledge, technical overviews (checked some out anyway), but just to be able to see the basic functionality.
So my questions are:
Where can I find any tutorials showing the basics and bare minimums needed for WIF to function in an explanatory manner? Preferably setting up WIF in a single MVC site combined with local authorization. Is there any step-by-step documentation at all?
Is WIF feasible, at all, on a single site or would the best option be to find other solutions like DotNetOpenAuth or use the separate APIs? When trying to get to the bottom of this, I have only found information regarding the value of WIF in large, multi-application, and platform environments combined with AD / ADFSv2. Which is completely outisde the bounds of what I need.
When I look at information on WIF, it's mostly linked to ADFSv2 and STS. Is this possible to implement at all for deployment on shared hosting for example?
Any input on the matter is appreciated.
WIF - see the How-to section here.
Also Get Started with Windows Identity Foundation (WIF).
Your best bet is probably to use WIF / ACS. Good link here or look at Windows Identity Foundation (WIF) and Azure AppFabric Access Control Service (ACS) Content Map.
The other way is to add OAuth2 to a custom STS. Refer Identity Server for a really good example of this.
DotNetOpenAuth definitely works on shared hosting, and requires no set up on the web server at all (it's just a .dll in your web site's Bin folder). Depending on the social networking sites in particular that you want to hook up to, it can be just a few lines of code to wire everything up if you're hooking up to OpenID enabled sites.
If the sites you're hooking to use OAuth or OAuth 2, there is more code to write for each individual site to work against their particular proprietary API, but that would also be true for WIF unless they have code to support specific web sites that happen to align with your own.
I'm designing a new web application. Some quick points on it:
ASP.NET MVC Web Application
SQL Server 2008
Entity Framework ORM
3 User Roles: Anonymous, Registered, Administrators.
Anonymous users can view stuff, Registered Users can post stuff, Admins can do anything
Heavy social integration with Facebook, Twitter and the like.
I plan to use OpenId for authentication (DotNetOpenAuth)
So, pretty simple right? (famous last words)
Now my question is:
Should i provide OpenId as the only means of authentication, or should i
also give the user the option to log
in using my own authentication system?
So this is basically a "User Experience" question. Take the example of StackOverflow - you MUST signup with OpenId. It seemed fine to me, but what about the general public? Can i be happy with the fact that a user of my site must have an OpenId account? (or signup for one before using my site)
Is giving the user two options to login bad UX?
I realize this is a partially subjective question, but im just looking for advice on which road to take, some case studies would be helpful.
Thanks.
Any good answer to a subjective question begins with it depends. :-)
I think if your prospective user base is already fairly social-network engaged (as it sounds by your description), it will probably be just fine to have authentication handled by OpenId providers. The important part is providing an easy-to-use login process, and make it obvious that various providers are available for authentication (Yahoo, Google, etc.).
If your prospective user base is going to consist of new or inexperienced Internet users, even a simple OpenId implementation may be too confusing.
I, for one, find it annoying to have to create yet another account every time a visit a new website, and I suspect that more and more users are feeling the same way.
There's a decent set of responses to a similar question at https://ux.stackexchange.com/questions/78
The thing is that only OpenID won't cut it in you case mainly because of Facebook and Twitter who aren't OpenID providers. Both use OAuth 2 for authetication. Wikipedia says this about it:
OAuth (Open Authorization) is an open standard for authorization. It allows users to share their private resources (e.g. photos, videos, contact lists) stored on one site with another site without having to hand out their credentials, typically username and password.
and this:
OAuth is a service that is complementary to, but distinct from, OpenID.
The DotNetOpenAuth also supports OAuth and the latest CTP release implements the OAuth 2 draft 10. Mind you that the OAuth 2 specification is still being developed and is expected to be finalized by the end of 2010. OAuth 2 also isn't backward compatible with OAuth 1.