I am confused about authentication with BlazeDS. Most of the few examples I have found for authentication and authorization in BlazeDS and consequently Java Servlets in general make use of HTTP basic and digest authentication and realms for authorization. These examples are very simplistic and involve XML files with the user credentials rather than using a database. My past experience in web applications used form based logins and sessions for authentication and authorization, but I am not sure how to do this with Flex apps with BlazeDS backends.
What I want to do is have some way to access some service on the backend to handle authentication like an HTML form and some way to store session data in a cookie for authorization, but I am having trouble finding relevant details using cookies in BlazeDS and Flex applications.
If HTTP authentication with either basic or digest authentication is the best way, then is there any resource to find out how to authentication users with the credentials stored in the database rather than an XML file?
I am not particularly interested in web frameworks since I would like to understand how to authenticate/authorize users with a plain Servlet and BlazeDS.
Authentication with BlazeDS and Flex is no different than with traditional web apps. Flex uses the same networking stack as the browser. So just follow instructions for securing your app server and then it should just work. If you want to have the login form in Flex then you can just send the credentials to j_security_check (for form based auth). Alternatively you can call login on the channelSet. Spring Security and Spring BlazeDS Integration M2 makes this very easy. Check out the Test Drive for a great sample (the usernames and passwords are still in an XML file but you can easily following the Spring documentation to move those to a database or LDAP server).
Related
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'm building a mobile application (that might also later become a web application). The server side is a ASP.NET MVC + Web API application and I'm thinking about ways how I could implement the service's user management and authentication.
How should I implement the registration/login screen in the app? Offer native app forms, that will send just API requests to the service or is it preferable to show a web browser component and display the website's login page and then extract a token after the user logs in? I see the first option is more user friendly, but the second one will let me change the login / registration page (like for example adding external authentication providers) without breaking older versions of the app.
My second question is regarding the external authentication providers. ASP.NET Identity has good support for them and it is quite possible to let users register using Facebook or some other OAuth2 provider. Does it make sense to add support for external authentication providers when I plan to expose the app's API publicly? Are there any reasons why that is not a good idea?
Your first option is best if you believe your users will trust you to manage their passwords. You make a secure call to your service, have the service produce a bearer token as the result. That would be an anonymous call. I used the answer from this question to get me going down that path:
Get IPrincipal from OAuth Bearer Token in OWIN
If your users are less likely to trust you with their credentials, then the web view and external provider is a good alternative. You would need to work with providers that support the "Implicit Grant Flow" since don't want to share the apps clientid and client secret on the mobile device. This approach involves using a web view to login in, and then capturing the token on the client uri fragment on the response. I think it is on a location header, but don't have a working example in front of me. Something like:
https://your.domain.com/#access_token = 8473987927394723943294
you would pass that token with each api call afterwards .
Good luck!
There is an existing mvc 3 application that is using asp.net Membership authentication (subclass of System.Web.Security.MembershipProvider). This application was only accessed using web browser.
Now, there is a need for the application to support a Mobile App, and I have already introduced WebApi 2 Controllers into the project for handling the Mobile App requests.
The problem is that I don't have a clear thought of how to Authenticate the Mobile App users.
It seems that I have to provide Token type authenticating mechanism where the Mobile App has to submit the Token (issued after authenticating) with each request. But I am not sure how to implement it (like what frameworks/packages to use), and get it working side by side with the existing MembershipProvider
So, how do I provide a way to authenticate Web Api requests, and also retain existing asp.net MembershipProvider for MVC Controller requests.
Also, if this could be done better in some other way ?
It doesn't have to be "token" that authenticate mobile users.
The notion of tokens used to authenticate webapi requests got a lot of attention because of the OAuth2 protocol that has been adopted to the .NET world by the DotnetOpenAuth and then the OWIN. OAuth2 supports multiple "flows" and what is interesting is that beside "passive" flows (where browser redirects to an external login page) there are also "active" flows (designed for active clients like mobile apps).
Thus, switching to OAuth2 means that you are using a coherent authentication protocol supporting all major scenarios.
One of the possible approaches for you (and you seem to be interested) is to adopt the token approach to authenticate webapi requests. This is possible but this means that you have two different authentication approaches side-by-side, the cookie-based forms authentication for passive clients and token-based authentication for active clients.
I would say this kind of smells.
I would rather think of a uniform approach.
Either move towards OAuth2 completely, which means you adopt DotnetOpenAuth/OWIN for both passive and active clients.
Or you stick with Forms Authentication and just enable it for your active clients.
The latter is rather simple. Instead of carrying tokens, your active clients carry forms authentication cookie. To issue such cookies, you just expose an anonymous webapi method that expects a login and password and appends a forms cookie to the response.
Assuming you clients support cookies, forms cookie issued by the server are used in consecutive requests and all you have to do is to have the Authorize attribute over your web api methods. The forms module will pick up the cookie and populate the IPrincipal for the lifetime of requests just like it does for regular requests.
To summarize:
Moving towards token-based authentication:
Pros:
in future you could easily handle more complicated authentication scenarios (like for example using external authentication providers)
token-based OAuth2 is commonly used nowadays so you can more easily integrate with other applications
Cons:
migration could cost: you first have to gain the knowledge, do some R&D and then migrate
Sticking with forms authentication:
Pros:
you already have it and you just enable it for active clients
Cons:
forms authentication is not really "an authentication protocol". This means there is no obvious way to easily integrate with external authentication providers/consumers
I have an ASP.NET web service that I can access via a windows program but now I want to secure the web service. I can secure the web service using forms authentication. How do you access the secured web service from a windows forms application?
Although this is not the right approach, tt is theoretically possible to use forms authentication in the manner you describe. This could be accomplished by either:
Using a WebRequest to send your requests in raw form to the web service. This will involve inspecting the response, extracting the relevant forms-authentication fields, and sending a response back which logs the user in. This will generate a cookie which you must send along with each subsequent response to the service
Generate the FormsAuhentication authentication cookie yourself. This is complex as it involves synchronising the machine key on the calling application, and artificially manipulating the headers being sent to the machine hosting the service.
Display the forms-authentication form for the user to log in to at the beginning of a session requiring interaction with the web-service. You can then harvest the generated cookie and present it to the service in HTTP headers as in option (2).
As you can see, these methods are highly complex, and are fundamentally a hack to use forms-authentication where it was never intended.
Microsoft intended us to use either Windows authentication, or SSL certs to secure access to ASP.NET web services. See HTTP Security and ASP.NET Web Services on MSDN.
If you are able to use WCF, then a few more options present themselves, including the ability to build a custom authentication mechanism into the SOAP, with some support from WCF.
For the most part, securing web services is one of the trickiest parts of the job. Many live solutions which I have seen are compromises such as the ones above.
It seems the answer is no. Forms authentication is a cookie-based mechanism, and your WinForms app won't be able to hold and relay the cookies (without some serious workarounds, if at all).
A potential workaround that I wrote up when researching your question attempted to use a NetworkCredential object, but that didn't work. Also tried was the ClientCredentials in .NET 4.0.
var ss = new MySecureWebService.MyServiceSoapClient();
ss.ClientCredentials.UserName.UserName = "abc";
ss.ClientCredentials.UserName.Password = "123";
string asmxReturn = ss.HelloWorld(); //exception returned here
The console app was still presented with the login html page when calling the webmethod.
Other Suggestions
If you have the source to your web service, extract its logic out into an assembly of its own. Reference that assembly in your WinForms app, and it's just as if you're calling the web service.
I understand that your goal is to reuse the app that's deployed, but the next best thing would be to use the same logic/implementation via .dll reference.
This might help: http://dotnetslackers.com/articles/aspnet/Securing-ASP-Net-Web-Services-with-Forms-Authentication.aspx.
We can successfully consume a .NET 2.0 web service from a Flex/AS3 application. Aside from SSL, how else can we make the security more robust (i.e., authentication)?
You can leverage ASP.Net's built in session management by decorating your webmethods with
<EnableSession()>
Then, inside your method, you can check that the user still has a valid session.
If you're talking about securing the information going over the wire, you can use Web Service Extensions (WSE) to encrypt the body of the soap message so that you don't have to secure the channel. This way the message can get passed around from more than one endpoint (ie. it can get forwarded) and you don't need multiple https certs.
If you're talking abut autentication then you could do forms auth with either a password in the body or in the soap headers (once again either encrypt the body or the channel). Or one of the easiest ways to secure a webservice (if it's an internal set of services) is have IIS do it, turn on NTLM and do authentication there. You can do authorization later on in the pipeline with an HTTPModule that checks peoples credential against the code they're trying to call.
Consider using WebOrb to communicate with your service. Here is some information on WebOrb's authentication mecahnism. There is also an article on Adobe's developer site on using WebOrb and .Net for authentication.
You should be able to use asp.net's authentication (such as forms authentication) without much extra effort. Securing an asmx file is just like securing an aspx file. There's a ton of information on forms authentication out there, just search for 'asp.net forms authentication'
If you are using Microsoft technologies you could build a little Asp.Net/C# application that would ask for credentials before redirecting to the correct swf.
That way you could restrict the access and have different swf file depending on the user.