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.
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 assigned to find a way of implementing SSO in our products. We have several Winform applications and one asp.net 4.0 web app (not MVC).
All the products are built using .Net 4.0, the web app is ASP.NET 4.0.
Some of the Winforms are commmunicating with our API via web services (asmx) and some uses our API directly. The web app is using the same API as well. We offer a set of web services (asmx) that uses the same API to external clients.
Currently we have our own authentication implementation (user, password, roles) in our systems and we would like to replace that with SSO. Or can these two authentication regimes co-exist somehow? The Winforms are used in intranets and the web app is used both in intranets and we also hosts the web apps for clients (accesible from the Internet).
The users are created in our system, but at the same time we import users from Active Directory using our own tool. Active Directory is really the primary user source.
I have read about Windows Identity Foundation and I wonder if I can use that to implement SSO. But what I don't understand is how to use WIF in the winform applications when they use the API directly.
What I would like to achieve is to remove all user administration from our system and use Active Directory as the user source. I guess that means using ADFS 2.0 to create claims, etc.
I can use .Net Framework 4.5 in this implementation (I know that WIF is now a first class citizen in .Net Framework 4.5).
Do you have any advices how to do this? Is WIF the best alternative to achieve SSO across winforms applications and web apps?
There is a way to get the WIF authentication cookie from within the WinForms application.
To do it, you just host the WebBrowser control and point it to the login page of your web application. Assuming the web application is federated with the ADFS2, the web browser control will automatically follow the flow - it will redirect to ADFS and stop there to show the prompt for user credentials (ADFS2 in Forms Authentication mode) or just authenticate using NTLM/Kerberos (ADFS2 in Windows authentication mode). Then the web browser will redirect back to your application.
This is where you hook your code. You just add a handler to the web browser's navigation event and you check when it comes back to your application AFTER ADFS2.0 authenticates the user. You can then call the InternetGetCookie method in the WinForms app to get all the authentication cookies issued by your application and you can close the window which hosts the web browser.
At this point, you have all authentication cookies issued by WIF (the SessionAuthenticationModule) for your application. You can now call your application web services and inject cookies into http calls. The web server will correctly recognize users as authenticated which means that all you have to do is to add proper authorization to your web services (the PrincipalPermission on your web methods should do).
An alternative approach would be to expose WCF services from your web application and guard them with WS-Federation active authentication. The downside of this approach is (in my opinion) that if your identity provider (ADFS) is further federated with yet another identity provider which DOES NOT necessarily implement WS-Trust/WS-Federation then the active authentication will probably fail (because the other identity provider does not implement it) while the passive scenario will still work (a bunch of redirects will sooner ot later end with a page which requires user to provide the credentials but the flow of authentication protocols between consecutive identity providers does not matter).
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...
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.