I've got 3 different clients accessing my ASP.Net service layer. I'm in the process of moving the Silverlight client to RIA services and I'd like to consolidate my authentication code if possible. I use a custom table in my database to store user credentials and profile information.
Can an ASP.Net Membership Provider be used for RIA, MVC and Web Service applications? Or is there an easier way?
WCF: http://msdn.microsoft.com/en-us/library/ms731049.aspx
RIA: http://msdn.microsoft.com/en-us/library/ee707353(v=vs.91).aspx
ASP.Net MVC: http://www.asp.net/mvc/tutorials/authenticating-users-with-forms-authentication-cs
I got myself tied up in knots a bit trying to use the same auth mechanism for RIA and a WCF REST & SOAP endpoints; RIA is a WCF endpoint at the end of the day. However consuming a RIA service is more comparable to using an MVC app; call a login service after which the browser or Silverlight app automatically attach a cookie to all subsequent requests which will be authorised by the ASP.Net membership provider.
Conversely clients of the WCF SOAP and REST services there are better ways to authorise requests rather than force them to call a login service, extract the cookie and attach it to all future requests. The above link for WCF actually describes a mechanism where the username and password are set for every request. In practice a lot of public web API's require a single header with a secret key to be set.
My conclusion is that I'll use the same membership provider for ASP.Net MVC and RIA but a different mechanism for SOAP and REST WCF services.
Related
I am working on a stateless ServiceFabric application that listens to some events and performs some business logic. I am looking at extending this application to expose web apis. But I am struggling to figure out how to authentication these web apis.
In the scenario, the caller of the web apis is an AAD application which runs as a background/daemon service without any user footprint. I want to pre-authorize this background application to call the web apis exposed by ServiceFabric application.
Can I get some sample code / documentation that describes such scenario. Planning to use OWIN to setup authentication and use JWT token, but all documentation talks about user token scenario.
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 am trying to do something like this:
I have a MVC4 Web App and a Web-API service (hosted on two separate roles in azure)
Another role runs CustomSTS1.
The MVC Web App trusts the CustomSTS1
Now the customer logs into the site he is redirected to the STS login page.
Once logged in, he is redirected back to the MVC Web Site.
From this web site, the customer performs actions, which in turn invoke the web-API Service.
I have the SAML token in the web app, which I pass to the WebAPI service.
Now when I try to validate the SAML token at the Web API side, I get a
Message=ID1032: At least one 'audienceUri' must be specified in the SamlSecurityTokenRequirement when the AudienceUriMode is set to 'Always' or 'BearerKeyOnly'. Either add the valid URI values to the AudienceUris property of SamlSecurityTokenRequirement, or turn off checking by specifying an AudienceUriMode of 'Never' on the SamlSecurityTokenRequirement.
This is without the Web API service trusting the CustomSTS1
Once I setup the trust,
I am always given a HTTP 401: UNAUTHORIZED, whenever I try to make a HTTP Get request to the WEB API Service.
Now, My Question is, (I know that my current approach is definitely wrong)
How do I setup the Trust relationship with the CustomSTS1, such that the WebAPI service is able to do an ActAS on behalf of the user logged into the MVC site?
OR
Is this architecture wrong?
And is there another way to achieve this?
That approach is wrong conceptually. The MVC application should negotiate a new token for the Web API in the STS using ActAs. That's how it traditionally works for SOAP Services. However, Web APIs are moving away from SAML as it is a complex format that relies on different WS-* specs. OAuth 2.0 is becoming the standard in that area if you want to support SSO at that level.
Another approach is to establish an implicit trust between the MVC app and the Web API, so all the calls to the Web API from the MVC app are done through a more standard Http auth mechanism like Basic Auth using an specific set of credentials that only the MVC app knows. The info about the logged user in the MVC app is passed as additional information.
Regards,
Pablo.
I have an internal LOB Silverlight client that uses business logic in a self-hosted WCF service (cross domain).
I'm thinking of using ASP.NET AuthenticationServices. How would I set this up with my self-hosted WCF service?
Call ASP.NET AuthenticationService from Silverlight to authenticate user? But this would not protect my self-hosted service...
Send username/password in every request from Silverlight and in my self-hosted service call ASP.NET Authentication Services? (Feels a bit backwards?)
Call ASP.NET AuthenticationService from Silverlight to authenticate user, send username/password in every request from Silverlight to allow logging etc, and use some other means to protect my service?
Is there some way to glue this together or is ASP.NET AuthenticationService not meant to be used when having a self-hosted WCF service?
All of the research I've done on the WCF Authentication Service indicates it's usage is for same-domain (RIA-like) applications. It sets the HttpContext.Current.User and creates a user session, so you can restrict your other WCF endpoint in some subfolder of the hosting website and control access via the web.config file. In this scenario, you can use the log the HttpContext user. If you plan to do things cross-domain, I think you'll find you need to use a combination of Transport (HTTPS) and Message security in the WCF binding configuration. This basically means your 2nd bullet point is true and you'll need to set the Username/Pw on the service client credentials (using Windows Auth or forms auth) and all WCF to send them across the wire with each message...
My scenario is a 3-Tier app where the data tier is a SQL Server database, the middle tier is a WCF application hosted in a Windows Service and finally the presentation is an Asp.Net MVC application.
As usual, the middle tier is the one that performs all of the business logic. Access database, define business rules.. etc.
Okay, so far so good! BUT now here's question: How do you handle security in such a scenario? I mean, the user has to log in on the ASP.NET application, but I want to authenticate it not only in ASP but in the WCF middle tier as well, since a WCF service is supposed to be accessed by more apps.
I want the user to log in on the Asp.Net application and let WCF know the credentials as well. Is there some kind of session in WCF in which to specify a logged in user?
How do pros handle security in this case? I know you can secure the WCF services with message security, but how do Asp.Net and WCF sync on a single logged user? I want to secure WCF operations depending on the user for authorization means.
I would suggest looking into using an approach like HMAC (Hash Message Authentication Code) for your security, or a similar token-based approach. The idea would be to sign your requests to your WCF layer which can be used to authenticate the request and identify the user making the request.
The essential elements would be a token and a shared secret of some sort used for signing each request. The token would allow you to identify the user on the WCF end, and lookup the shared secret to verify the request. You can also added timestamps / nonces to prevent replay attacks and such.
I've used this approach for some REST services built on WCF - with the added benefit that clients do not need to store usernames and passwords, just the security tokens used for communication. In your case you'll need to sort out how to exchange the tokens between the ASP.NET layer and the WCF layer, but it would provide you a unified authentication method for any consumer of your WCF services.
Have look here for UserName Password authentication.
ASP.NET Web Site + Windows Forms App + WCF Service: Client Credentials //for insights