Hi I am building a centralized authentication structure for all our applications in our intranet.
I have tried using a Jwt Web Api.
I have tried Identity Server 4 OpenConnect
And now i found out Cookie Sharing from Microsoft docs
https://learn.microsoft.com/en-us/aspnet/core/security/cookie-sharing?view=aspnetcore-2.2
I can't decide even after reading so many articles already which one should i implement.
The cookie sharing sounds very simple to do, I downloaded the sample and it worked right out of the box.
The identity Server 4 samples all have some problem that i can't run. Some functions like log out won't work or only works on one end.
The Jwt Web Api wasn't very hard to implement but still requires to thinker a bit to get claims from the token and then implement token refresh.
The cookie sharing i just found out but i'm still open for more alternatives or pros and cons each of these.
I also heard about OWIN but still don't understand exactly what it is
AFAIK
Cookie Sharing
If all of your applications are on the intranet and are all made using the dot net stack. It makes sense to take advantage of the sharing cookies. I previously had success implementing SSO using this strategy where the main login would be an old web forms application and it would authorise a dotnet core app.
Pros: You are using the Microsoft stack, easy to setup.
Cons: You are locked to using the Microsoft stack. Falls over if you want to use with native/js applications.
IdentityServer4
Having experimented quite a bit with this library, this is an abstraction of the OAuth2 and OpenIdConnect protocols, essentially authentication and authorisation using jwt tokens. IdentityServer4 allows you to specify your authority (AS => Authentication Server) which is handles authenticating clients (your other applications be it .net, js or native). The token that the AS gives the clients are then used to determine if the client has access to the an API. You get to specify which clients can access which api's and how much of it can they access based on Claims. It is possible to convert Active Directory groups into claims and authorise by that level.
Pros: Really good abstraction they simplify a big part of the process. You can secure any type of client (js/native/.net).
Cons: You still have to learn OAuth2 & OpenIdConnect specs, which can take quite some time. You'll probably endup writing quite a bit of configuration depending on how big the network of apps that you are trying to secure.
JWT Middleware
This just allows the api to authorize tokens against an authority, and it doesn't really provide the "centralized authentication structure", you will have to handle alot of the flow setup your self. generally just a watered down version of IS4.
Pros: fast and simple way to secure an api to an already existing Authority.
Cons: Doesn't allow you to create a Authentication Server.
Summary
I'd say go with Cookie Sharing if you don't plan on securing native apps or js apps.
If you are setting up token based authentication read below.
Go with IdentityServer4 for long term flexible solution and if you have time to learn how to use it and set it up.
if you have an authority and don't mind doing a bit of setup go with JWT Middleware, this will be a bit more flexible than Cookie Sharing.
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
Can 2 projects in one solution share the same login page and web.config
under one solution? I have 2 UIWebProjects, 2class libraries for the Business layer and Data Access Layer.
What you are trying to achieve is named Single Sign On - Single Sign Off scenario.
There are many ways to incorporate SSO in asp.net application , however i would recommend to use WIF (windows identity foundation) as it is part of Microsoft stack for SSO which will also allow you to use other means for SSO like SAML2 or AD etc
you will need to implement one identity provider( IdP , STS in WIF terms) web site and two service provider web sites (or you can use one website as both IdP and SP however i would separate it.
here is an article to begin with, also google WIF and lookup WIF tag on stackoverflow
What you're looking for is called single sign on (or cross site authentication). Here are some resources:
ASP.Net Cross-Site Authentication
http://www.codeproject.com/KB/aspnet/CrossDomainSSOModel.aspx
I dont think so, never done it.
But you can call one login page from both the application and depending upon the call, redirect url to the respective application page.
We have an ASP.NET MVC application that uses Forms Authentication to create and validate the authentication ticket (cookie). The log on flow is very special, not just username/password, but it ends with a call to FormsAuthentication.SetAuthCookie(userId, false) to create the cookie. So a standard cookie is created, it is just how it is created that is special.
We will also have to integrate with a couple of other web sites that are not neccessarily .NET based or not possible to customize via some kind of Single Sign-On that do not require any modification on the other sites. All sites are behind the same UAG/ISA Server.
Is it possible to setup some kind of filter in UAG/ISA Server that can validate the Forms Authentication cookie created by the ASP.NET MVC application? If it is not OK it should redirect to the log on page in that application? If it is OK it should just let the request through. For example, would it be possible to use a ISAPI filter with UAG that does this? We can use the same machineKeys on the UAG server and the ASP.NET app server (I guess that is required to start with)
I don't know much about UAG and I'm also interested in alternatives to UAG. In fact, what we really need is just something that works as a perimeter protection for all those sites and that can utilize the already existing log in flow/cookie.
I am building a web based application written in ASP.NET and Flex. One of my biggest challenges is implementing security for the application in a flexible and maintainable way. This challenge is compounded when different technologies are involved. I'll try to describe what I have below.
The website is laid out as follows:
/mydomain.com/
Login.aspx
Default.aspx (hosts flex [.swf] application)
/Administration/
AddUsers.aspx
AddRoles.aspx
AddPermissions.aspx
etc...
/Services/
SecurityService.asmx
MapService.asmx
PhotoService.asmx
etc...
I am currently using forms authentication to secure the resources on the website. All pages/resources not in the /Services/ folder require an authenticated user and will be redirected to Login.aspx if they are not yet authenticated. The .asmx pages allow unauthenticated users. To secure these resources I throw an exception in the SOAP method. This avoids redirecting pages for SOAP web services which is not supported by any SOAP web service clients I am aware of. Finally, SecurityService.asmx contains a Login method to allow the Flex application to Login without redirecting to the Login.aspx page should the cookie expire for any reason. Because the cookie established is sent with any request to the server, including requests coming from the Flex application, this seems to work pretty well.
However, this still feels like a bad approach securing web services. I feel like I am using Forms Authentication for something it was not intended for. Specifically, I am concerned about:
This model will not work when the services are separated from the core website. This is a newly discovered requirement and I believe that Forms Authentication is not going to work well (if at all) without a lot more modification and trickery.
Clients other the Flex may require access to the services. Some of these clients may not even be able use cookies. If so, this model immediately falls apart. This is not an immediate requirement but it is known that this is one of the long term goals.
We will eventually (hopefully sooner rather than later) move to a REST based architecture (vs. SOAP) so any solution needs to work for SOAP and REST.
So, my question is.
What are the best authentication and authorization mechanisms for securing an application built on ASP.NET, Flex, and SOAP or REST web services?
Note: I am actively looking into OAuth; however, I am having a difficult time finding complete examples from which to learn. Additionally, I need to be able to filter the data returned for a given user based on the permissions that user has, OAuth seems to remove the identity of the user from the token. As such, I am not sure how OAuth applies in a fine grained security model.
Others may disagree, but I actually don't see a huge problem with handling it the way you are now; that's probably how I'd handle myself, at least initially. One way or another, even down the road, you'll probably want to keep the Flex app aware of the authentication state of the session, so if that means checking the ASP.NET session token directly, or some other cookie you set when you set that one, it seems like a fine and reliable way to go.
I do see what you mean about the services redirecting, but even so, with forms auth, it's not so much the service specifically that's handling the redirecting so much as the ASP.NET app itself. Later, should you need to use a different authentication scheme, you can consider that scheme's specific implementation considerations. Unless you've got concerns about using forms auth in general, there's probably no need complicate your approach simply because of the Flex client and Web services.
I admit I don't work with web services much, but what about requiring an access key as a soap header parameter? Any client app which can communicate with a soap web service is likely to have a low level API to modify the soap request, and use of the access key allows you to (in theory) limit the use of the service. Google, Amazon, and several other providers use this type of authentication for their web services and it seems to work very well.
This article seems like it might be a good place to start...
The WCF Security Guide published on CodePlex may help you there, if you are using, or can use WCF.
There's also Microsoft's Web Services Enhancements (WSE) 3.0 which I believe implements some of the WS-* security specifications.
Hope that helps.
If you move your services to another place, then the standard ASP.net authentication cookie can be re-used if both web apps have the same machineKey in the web.config.
As far as I know, FLEX will honour the asp.net authentication cookies because it will make http requests through the browser, which will pass the http cookies (including the asp.net authentication ticket) like a normal http request.
Have you tried securing your website and services using normal asp.net authentication yet?
I think it's best to have independent authentication systems - even if there are relations between the user and the auth tokens on the back end. They are different beasts that have differing capabilities and demands.
Use the normal forms based auth for the flex portion. That is good.
For web services, you could create a login method that returns some auth token which is used by subsequent tasks to execute. Or add a few fields to your web services (posted in the header or as params) to use a userid/password combo for authentication each and every time.
A side note: I wouldn't rely on a soap exception to handle authentication problems. But you wouldn't need to worry about the redirection if you send an auth token or user/pass with the WS requests.
EDIT:
RE: Comment-
Ideally there is. There are products out there (Tivoli access manager) that service those needs, but they are expensive.
I gave this recommendation because it eases the pain of allowing access to alternative clients and as long as you designed the services correctly it's stateless. It also gives you finer grained control over data level access on the service side of things.
See Web Services authentication - best practices?
Dave Dunkin wrote:
The easiest way to handle it across a
variety of platforms is to use HTTP
basic authentication and HTTPS for the
transport layer. WS-Security would be
good if your needs go beyond simple
username/password but the support is
going to vary quite a bit between
platforms. HTTP authentication is
supported by every decent SOAP
implementation.
and my Custom HTTP Basic Authentication for ASP.NET Web Services on .NET 3.5/VS 2008.