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
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'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
I am working on integrating our application with client's Identity management system using SAML 2.0. Below is the requirement
The login screen of our application will have an option for Single Sign On. when clicked user will be directed to the login screen of Identity management system
The Identity provider will validate user's credentials and send us the information back to our application
based on the input from Identity provider the application has to be provide access to the user.
Now, the client has asked us to provide them SAML meta data files. Our application is developed in dot net.
I had a look at component space and ATC Inc components that can be used for SAML generation however I need help to start this.
Can someone help me on this? This is something new which I haven't worked.
Thanks,
Abhilash
If you are looking for a simpler integration than coding support directly into your application, check out the PingOne Application Provider Service (APS) "SAML as a Service" from Ping Identity. A handful of lines of .NET code (or Java or Ruby or Perl, etc) to integrate via a RESTful API and you're done. No need to embed complicated SAML SP code and the security overhead that comes with it [Disclaimer: I do work for Ping].
HTH
Ian
I'm using Asp.net c# language programming.
What is the best way for authenticating web methods in a web service?
Is it right having authentication for every web method and verify user name and password for each web method?
Is there a way to authenticate just once not for every web method? something like using sessions and etc?
You might want to look into this one:
http://weblogs.asp.net/cibrax/archive/2006/03/14/implementing-a-secure-token-service-with-wcf.aspx
Edit
If you are bound to only use asmx for some reason, then I would also suggest looking into WSE from MSFT.
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=018A09FD-3A74-43C5-8EC1-8D789091255D
You can pass around a token from your client into the web method. The token is encrypted with public/private keys.
For more info here:
http://msdn.microsoft.com/en-us/library/ms996931.aspx
First of all, you should be using WCF for web service development unless you're stuck at .NET 2.0.
Secondly, you can use Windows authentication or Basic authentication over https, but those restrict you to users who are Windows users. If you have a separate set of users, then you will need to do your own authentication.
You can use SOAP Headers so that you don't need a username and password in every web method.
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.