I am looking for a Rails API for a federated id service or cloud sso. I've been playing around with the idea. Of CAS and omniauth but for an enterprise-ish app it would be better if it could auth could be unified across all applications a small biz might use.
There's many different options for a Federated ID using Rails. Gatekeeper is a very good one that I've heard about and most people I know talk about.
Another one that is very young compared to other is oPro which basically simulates OAuth 2 on your Rails App you can find it here oPro.
In my opinion and experience working with federated IDs in enterprise projects I'd suggest looking into implementing it yourself which is just a matter of following the documentation of whichever one you choose.
Related
So I have been looking into OAuth lately, I want to authorize another of my domain which has separate database using OAuth. Upon searching I found auth0.com. Which sounded similar to Oauth and I created a sample implementation, it offers support for custom databases also. We have users stored in external api running on .net core, and I learnt that auth0.com is not free after trial expiration. So my efforts kindof got wasted. Now I am looking for authorization method that works for both domains.
Now my question is, does it even make sense to use Oauth for this task? Since I won't be giving it to third party and it's matter of two databases. How should i approach this and what are opensource Oauth services that allow custom database.
I'm working on building a closed community forum for members of an existing site I also built. I'd like to allow members to sign in to the new forum using their existing accounts on the main application. The forum will be on a different domain from the main site.
This will be my first time using OAuth. Most information on the web about it seems to skew heavily toward allowing users to sign in with Twitter/Facebook/etc accounts, and there's very little information that seems pertinent to what I'm working on.
I'd like to create an OAuth provider in the original web app and a OAuth client in the new app I'm building. No other providers will be used, and no other client sites will be authenticating off this main site. Additionally, I need to avoid any sort of "authorize this web site" intermediary step for my users.
The main site is Rails 4 with Devise, and the new site is Rails 5. I'd like to stick with Devise on the new site as well, which I understand can function as an OAuth client. Doorkeeper seems like it could be overkill for my exceedingly simple needs, but most other information I've found is years out of date, so I don't want to invest time pursuing an implementation that won't work or is not the current best approach.
What is currently the best way to handle this kind of single-client, single-provider setup?
I feel a bit overwhelmed right now with how to approach building an SSO solution for a project I'm taking on. I understand that I need a centralized login site, but, I'd like input on what framework I should be using to achieve this. I've been reading a bit about Windows Identity Foundation (WIF), but, the lack of documentation and code samples is quite disappointing. DotNotOpenAuth sounds like it has much more usage by the community than WIF, but, I'm not sure if that's the right framework for me to use given that I am not going to be letting third-party accounts be used for logging in.
There are multiple user data stores to take into account as well; active directory and a SQL Server database.
I really don't care what framework I use so long as it's simple and intuitive; I don't want an overly complex solution. Documentation and samples are also a plus! I already have experience with creating custom role providers and membership providers; those were a breeze and easy to do.
Here is a very quick visual of the structure I'm dealing with:
Refer: Claims Based Identity & Access Control Guide and Identity Developer Training Kit. There's WIF samples there.
In terms of what you want to achieve, ADFS v2.0 will get you most of the way but it can only authenticate against AD. For SQL server, use IdentityServer and then federate ADFS and IdentityServer.
Have a look at SAML. It is designed to address SSO. You may also want to look into OpenID.
There are enterprise products out there, such as CA Site Minder or IBM Tivoli for this kind if thing. They are not cheap because building a custom solution for this will be quite a feat.
If you are .NET based - then .NET 4.5 (which includes WIF) is the way to go.
But the framework will be you simplest problem. Building that kind of security infrastructure is hard. Have a look at both the book and idenitity server from nzpcmad's answer as a starting point.
As far as cross-platform goes, SAML tends to lead the pack. There are many implementations (java, php, perl). As Dominick (#leastprivilege) mentioned, if every application is .Net based, WS-Fed via WIF is the way to go. (btw, Dominick is the man when it comes to WIF - definitely hit his blog and forums up if you plan on exploring that route)
OpenId and OAuth are alternatives that you will hear about. They are somewhat less secure (the trust is in the user, rather than the infrastructure) and you will find that you will have to build a provider in order to support sign-in using your own user store.
Regardless of the route you choose, be prepared to do a lot of reading and learning. Check out the wikipedia articles above for a nice overview of how these technologies work, and don't be afraid to ask questions..
I've been research WIF a lot recently and am still quite a bit confused about some of the specifics. I understand that if you're using ADFS that it's great, but that is not my scenario. Within my organization there are at least 3 main security systems. I have tried to get the company to use AD for all internal uses, but it's just not going to happen. In order to create a unified programming model, I've contemplated building add'l STS's for authenticating/authorizing.
Is this really wise? Most of the stuff I've read says just use ADFS. If not, then don't bother. Is it worth using WIF for the unified claims model when the process of creating custom STS's can be difficult?
What do you do in a case where not every user has an AD login to map to. For example, we have many seasonal employees that never actually log in to a machine with a personal account. The machine is logged in in the morning by a supervisor and the employee scans his/her badge and the employee id is used.
We are creating a new application whose code base will be accessed by at least three different sets of users. One group is internal (using AD) the other two would probably use asp.net default membership (okay, so two different sets of user stores). I'd love to be able to use WIF to unify authorization/auth, but with WIF it seems to want to go in the opposite direction. It de-emphasizes authentication and just kind of assumes it's all good when in many case that is the main concern. How could I leverage WIF in this scenario, if at all?
I've tried reading this article:
http://msdn.microsoft.com/en-us/library/ff359105.aspx
and I read up on StarterSTS which I still need to read up on a bit more. I've also watched the videos by the author of StarterSTS. I'm failing to really put everything together. It feels like WIF won't be useful for me, but I feel like it should since all I'm really after is a unified model of authentication and authorization. Thanks
What you want is similar to the Federated Identity model. You can build a Federated STS (like StarterSTS) that would normalize your claims for your application. You can then use something like ACS / AD FS V2 to federate these Identity Providers. Reading the Claims Based Identity Guide is a good start as well. When you Claims enable your application you can add more and more Identity Providers and use the Federation Provider to control the claims and set rules.
We just released a new version of the guide on CodePlex (the docs and code) while it goes through the production process.
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.