I've been reading a lot about OpenID and OAuth but having trouble making just a few connections about how they would work in a service-based architecture.
Here's my scenario:
I'm writing new ASP.NET Web API services (RESTful/JSON)
These services will be used by client applications (current desktop website, new mobile website, and possibly a PHP website or JavaScript-only client in the future)
Our desktop website currently uses ASP.NET Membership Provider (webforms)
The new set of API services we are creating should handle everything, including Authentication and Authorization.
My questions are:
Since we have explicit control over the client applications accessing our API (i.e. this isn't a public API but rather one for integrating approved partners) do we necessarily need OAuth?
Would OpenID replace our .NET Membership functionality, or complement it?
Given that we would need to authenticate users with the legacy system using Membership Provider, do we need to use some sort of .NET Membership OpenID Provider, or do we just authenticate as usual and grant the user a Membership Token like we currently do?
I guess, in summary:
I'm writing some new services
They should be usable by ANY approved client application, for users of that client application
We need to continue to support our .NET Membership data
Sorry these are basic questions but I'm sure they're easily answered. Thank you!
Look at ThinkTecture's Identity Server
https://github.com/thinktecture/Thinktecture.IdentityServer.v2
It uses repository patterns for user stores, and uses the default membership provider as the user store - you would be able to easily plug-in your legacy membership provider.
OpenID connect would work on top of your membership provider, and you'd enable the option to only allow registered relying parties - meaning that only your approved clients (applications) would have access.
This seems like a perfect fit - hope this helps.
Matt
Related
In most cases, I have used AD to lock down applications through IIS. In this case, I need to create an MVC Application that will have some Web API controllers and authentication/and authorization (roles). I was looking to try to use a stack overflow suggestion that I have found to several other posts.
https://identityserver.github.io/Documentation/docs/overview/mvcGettingStarted.html
Most of the answers that I have seen in Stack Overflow reference the above link
ex). Implementing Authentication and role based authorization in ASP.NET MVC web API service and MVC client architecture
The question that I have for the community that has experience with adding Authentication/Authorization to a combined Web Api/MVC project is if the identity server approach listed above is the best solution for this scenario and if there are other resources that I should look at also?
From your requirements (authenticate to use an MVC site and then be authorized to use a Web API) you'll need an OpenID Connect Provider such as Identity Server 3 (aka a Security Token Service (STS), an Authorization Server, etc). Basically something trusted by both the MVC site and the Web API.
The basic flow of things here is that your users will authenticate using OpenID Connect on your MVC site, after which they can get an access token to authorize access to the Web API using OAuth.
The mentioned tutorial is the best way to start. Near the end it takes you through how to access the API on behalf of the user.
ASP.NET Identity is a user/identity store. It is not add authentication or authorization to your application.
I'm very new to the identity management world, so please spare me. :)
What I would like to do, is to have multiple client (MVC) applications that talk to a single Web API application to authenticate their users against. In that Web API application, I would like to use ASP.NET Identity to talk to a database with users.
That way, I could use SSO for the client applications (I guess).
Does that make sense? Could someone help me on my way to implement this (links are also welcome of course)?
I don't know if IdentityServer could help me with what I want?
And as a side question: when I could implement this the way I would like to, how do I deal with the same-origin policy?
Thank you for all the help. :)
I did some research myself during the last few months and I learnt a lot about the identity management stuff. Many of that also thanks to the guys from IdentityServer (and their other projects).
What I finally did was the following (very briefly):
IdentityServer is used as a provider for all client applications. The cookie and OIDC middleware are used.
I used the ASP.NET Identity user service to store the users in an SQL Server database. (The IdentityServer configuration is by the way also stored in a database.)
I set up a Web API service that uses the ASP.NET Identity user manager for user configuration (change password, create new users, ...). It uses bearer authentication with the application with IdentityServer as provider.
As a side note, IdentityManager is used as an internal admin tool to manage all the users.
If anyone is looking for some help setting up his / her identity management system (and thinks I can help): please ask. ;)
Many articles on active profile e.g. Federated Security: How to setup and call a WCF service secured by ADFS 2.0. But that article assumes you want to use AD?
I'm guessing you want to use ASP.NET Identity for the provisioning?
IdentityServer OOTB supports a SQL DB and has basic user provisioning built in. It allows users to authenticate against the DB and supports WIF.
This scenario is also close to what you need, take a look at the answers:
How to implement an OWIN Authentication server with a MVC Web Api content server and an Android end-user apk
I also recommend reading this article:
Decouple OWIN Authorization Server from Resource Server
I am currently evaluating possible Identity Management (IdM) solutions that enable single user identity store and SSO across applications.
I am leaning heavily toward Thinktecture IdentityServer v2, but I am not able to validate that all of the following requirements can be met with it.
I am also familiar with and have used the MembershipReboot project as a replacement for the ASP.NET Membership Provider. I like it that MR provides a lot of the self-serve and pwd mgmt requirements I'd need, but I don't fully understand how this would "fit in" with IdentityServer - and by that I don't mean the actual implementation of the I*Repository interfaces, but rather from a high level architecture.
Would someone tell me which of the following are (or are not) possible with it, and perhaps provide other options that may better address these requirements?
Support for ASP.NET (WebForms and MVC)
Maintain central user identity store
Self service password management
Password policy configuration
Ability to authenticate both AD users as well as user in SQL store (centralized)
store (forms) - this means we want to have some internal users (AD) and some custom (forms/sql) users in the same application
Customization of pages (e.g. login, self service, etc.)
Roles/Claims management specific to each application (I know this is
Authorization, not Authentication, but I need to understand how to
manage app-specific claims related to central user identities)
Permissions management (not sure if this should this be in app, or centralized)
SSO across different domains
Support for token standards like SAML 2.0, JWT, WsFed
Open Source, or Low Cost
Extensible (lower priority)
Any suggestions/recommendations or comments based on the above requirements?
If you're using IdentityServer then you're doing single sign-on. This means your app can be any tech as long as you have a library that can handle whatever protocol your IdP supports. IdentityServer v2 supports WS-Fed primarily for browser-based applications. IdentityServer v3 will first be focused on OIDC (OpenID Connect) but will eventually also support WS-Fed.
MembershipReboot is an identity management library. This means it stores things like passwords and other identity data for your users. It can be used by both IdentityServer v2 and v3.
Most, if not all, of the things you list can be achieved with either platform. Some will require custom coding on your part.
IdentityServer v3 will be in alpha very soon.
i'd like to recieve comments on the way i'm trying to build an asp.net web application which uses a WCF service that is hosted in another asp.net application. Both applications will live on the same machine, but the app with the WCF service will not be accessible from the outside. there will be two web servers sharing the load behind a load balancer.
The app pool of both applications will use the same local user account (web server is not part of a domain) and so i was thinking to use WsHttpBinding with windows security for communication between client and internal wcf service.
The fron-end asp.net app uses forms authentication through a custom membership/role provider to athenticate and authorize users. The user database is in a sql server database.
i need to somehow pass to the wcf service the user details (username + roles) so that in the wcf it will be possible to validate and authorize according to the roles of who is logged in the front-end. I read i need to use "support tokens", but i haven't figured out how to use this.
I read also something about claims and WIF, which seems interesting but have no idea how i could use these in my scenario.
is there anyone who can give me recommendations about the architecture and maybe also show me how to pass the username to the wcf service and also show me if possible to use claims based authorization?
First of all, if both servers are behind the corporate firewall on a corporate LAN, I would strongly suggest using netTcpBinding instead of any http based binding. NetTcpBinding is much faster due to encoding the message in a binary format.
As for username / password: your ASP.NET front-end server could set the client credentials for the user calling for the WCF service - after all, the ASP.NET servers do have access to the ASP.NET membership database, don't they?
Or if you cannot pass on the user's credentials, you could pass on some headers to your WCF service that would describe the user - actually, you probably only ever need the user's unique ID - since the WCF service could fish out the rest of the info from the ASP.NET user database again, if really needed.
As for claims - I don't think they'd be a good idea here - you don't really have to deal with a multitude of different authorization schemes, and you're not using any federation (e.g. allowing users from a different company or domain to use your services) - so those obvious benefits probably won't really be applicable to your case.
I've been playing around with ASP.NET Application Services. I've implemented the Authentication Service, Profile Service and Role Service successfully, able to log in and get Profile information for the logged in user and Role information.
Now I've noticed a major shortfall in the fact that I can't work out how to create a new user account with the Application Services stuff. Does anybody know how?
Seems like the Application Services AuthenticationService only supports validating existing users. You should enable creating users through some other part of your application, either your own web service or a web page.
I'm not sure about Application Services, but I know that you can create new users with Membership Services.
That's like this:
Dim mbmr As MembershipUser
mbmr = Membership.CreateUser(newUserName,newUserPwd)
There are something like 6 overrides for the CreateUser method.
I think not many people are not fully understanding the role of application services and thus feel frustrated when they do not find the full asp.net provider stack exposed over a store bought json endpoint......
Application services are exposed publicly. They are meant to provide an authentication and identification facility.
Think...
Your user is not logged in. To log in you must access application services to authenticate.
Right?
Do you really think that exposing membership management api such as Create/Delete user on that endpoint is wise?
Exposing management functions on a public facing api presents a huge challenge to get right for ONE scenario, much less to capably facilitate every scenario so perhaps you can see why application services exposes only what you need to do identify and authenticate a user.