Within our organization, our applications are registered as RP’s to our organizational ADFS server, which is v2. Traditionally, apps in the org have been built as single, monolithic apps using WS-Federation (passive authentication). Web API’s, also hosted within each app, are secured simply by the fact that the same FedAuth cookie is being sent over the wire when making the ajax calls from the app’s client-side code in the browser.
We are moving towards building a set of backend Web API’s, which we want to secure so that these are callable by any client, not just a web browser and not just by the hosting application itself. As such, we want to move towards using JWT tokens for these Web API’s. We've also started using ThinkTecture's IdentityServer (v2) to help in this regard.
We have just a few questions which I'm hoping the community can help provide us with some answers/pointers:
How should we configure IdentityServer and apps so that the apps use
the existing organizational ADFS login page?
How can we configure/integrate ThinkTecture IdentityServer v2 with
the organizational ADFS so that our API's can be secured using JWT
tokens but without forcing the user to provide their credentials
again (once they have a SAML token via WS-Federation)?
Are there any features in IdentityServer v3 which are compelling
enough to upgrade from IdentityServer v2 to v3?
1 & 2 - You might want to check out how to establish Relying Parties. Here's a whole article from BrockAllen (the genius behind IdentityServer) that walks you through the ADFS/IdentityServer2 integration.
http://brockallen.com/2013/04/14/getting-json-web-tokens-jwts-from-adfs-via-thinktecture-identityservers-adfs-integration/
3 - As far as I know, IdentityServer3 (IS3) was written to support newer authorization frameworks OpenID for the modern stack better than IS2 (which doesn't support OpenID). Either is fine for use. I personally started with IS3, mainly because of the support and documentation involved. It also integrates very well with OWIN/Katana, so it can self host reasonably well with no hiccups during implementation and deployment. One advantage IS2 has over IS3 is that IS2 has an admin UI you can use configure and register sites, IS3 doesn't. More info about this along with the thought process behind IS3 can be found here:
http://leastprivilege.com/2015/01/25/identityserver3-1-0-0/
Related
We are in the process of developing a mobile (native) app, and are looking at how we should do user authentication. Most of the information I have found have been about web apps and / or third-party apps accessing public APIs. OAuth 2 is therefore recommended to be used most of the time.
Since we develop the app and our API isn't public, it seems like the Resource Owner Password Credentials OAuth 2 flow could be an option, but according to oauth.net that is not recommended any more.
We are using Google App Engine (with Node.js) and Cloud Endpoints (Not sure if end-points would be needed since it's a private API, but that is another question) as the back-end, and both Firebase Auth and Auth0 has built in support in Endpoints. However, we have some special requirements that doesn't make those services suitable (Swedish BankID for example).
What other options are there when authenticating users? Could we write an app in App Engine to check the users credentials against our database, and then send back a JWT (Cloud Endpoints supports custom authentication methods as long as they use JWT)? Would it be safe to do this ourselves? I have found some Node.js libraries for authentication, but most seem to be aimed at web apps. Are there any that are suited for a native app front end?
For authentication, yes, you can perform the check yourselves, in your database and deliver or not a JWT according with the authentication result.
However, and it's obvious, this authentication service must be public (because it's for authenticated unauthenticated users!). And thus, you can be expose to attacks on this service. And because it's the authentication service, if the service goes down, no one can no longer sign in, or worse, if you have a security breach, your user database can be stolen.
That's why, to use existing services, with all the protections, all the resources (people, monitoring, automatic response, high availability,...) deployed to managed a large number of threats. Firebase auth, Auth0, Okta (...) are suitable providers but I don't know your Swedish requirement and you might not avoid specific developments
I want to implement login and logout functionality and retrive user details like username and user role using Azure Active Directory.
We are using Docker to deploy Spring cloud microservices project on Azure cloud. Could you please suggest me steps to get user details?
Do we need to secure all microservices edge points using Spring cloud OAuth2 security using JWT or just we can secure one web microservice ? Do I need any permission ,specific user roles to implement this?
You can find Azure's documentation about OAuth 2.0 support for AAD here
https://learn.microsoft.com/en-us/azure/active-directory/active-directory-protocols-oauth-code
I've got an application that's using OAuth 2.0 with a different Authentication Server, and I'm about to see if I can use AAD as the Authentication Server. But, whatever ends up being your Auth Server, the rest of the application should be the same...
The Auth Server handles the log in (typically as a Single-Sign On pattern)
The Auth Server will return a Json Web Token (at some point, depending on the Grant Type being used to retrieve it)
The JWT should be included in each subsequent request to ensure the caller has authorization
From a Spring perspective, you'll need at least a SSO Client (denoted by the #EnableOAuthSSO annotation). If everything in hosted by that process, you'll need that JWT to call subsequent methods. If you have processes hosted in other processes, it's likely you'll want them secured as well. Using the #EnableResourceServer annotation will configure Spring Security to look for the JWT, just not attempt to retrieve one if the request does not have it.
Unless the endpoint is meant to be publicly accessible, you will want to secure it. Of course, I really don't know the context of your application, so this statement is purely an uninformed opinion based on zero knowledge of what you're trying to do with your application. Take it for what it's worth.
EDIT
This has become a little more complex than I originally thought. I have been able to write some code to dynamically retrieve the public key from Microsoft in order to validate the returned JWT.
But, the main issue is the fact the Azure AD supports Open Id Connect when acting as an Identity/Authentication Server. And, at the moment, spring-security-oauth2 doesn't support Open Id Connect.
I was able to make some small changes to the spring code, but I did ask the question to the Spring group and they are actively working on adding support for Open Id Connect. They hope to have a release two months (ish?).
For the short term, the oauth2 support doesn't support Open Id Connect. Given this is the protocol used by AAD, the current version of oauth2 won't work with AAD. That said, I will be happy to wait for the official support which shouldn't be too long.
At the moment we are building a web shop as a SPA application. All the SKU information is provided by a Web Api 2 service.
Of course the web shop is publicly available to every visitor, and currently there is only one user who can log in to manage the web shop: the administrator.
For the administrator we built in the basic authentication with the bearer token, as a lot of samples on the internet shows us, but now we need every user to log in before they can see any product. Not really what we have in mind for a web shop ;-)
What we would like to implement is that our Web Api is not available to the world but only for our SPA application. Every blog post or tutorial on authorization seems to assume that there is always a user that needs to log in, in our case there is only one user: the administrator.
The AllowAnonymous attribute makes specific API calls available to the world again, so that's also a dead end.
Basically it comes down to preventing any other apps (web or mobile) to fetch the data from our Web Api.
What would be the best and most secure approach to secure our Web Api without having the anonymous visitors of our web shop to log in?
Solution for now: Altough I'm not 100% happy with this solution, it will work for now. We implemented the OAuth Implicit flow with CORS enabled for specific domain.
You should take a look at the OAuth 2.0 client credentials flow. The client in OAuth speak is the application and not the user using the application. This way you can make sure only your SPA app can access the backend API.
The parts that only should allow access to the administrator, you can decorate with the [Authorize(roles = administrator)] attribute, which prevents any other roles from having access.
I think Json Web Token could help you with this. This article has more information about using Json Web Token for granular authorization of your web api.
OAuth 2.0 is inherently insecure, and solely relies upon SSL. It has no encryption, and most of the latest web api gurus are suggesting that it's dead. This again is relative to what you need the security for. If it's for a social SPA where the data isn't financial or medical, for example, and good enough SSL security is ok, then perhaps OpenID or OAuth2 is suitable.
A much better solution is to implement Identity 2.0 for the Web API authentication flow, and then utilize something like Hawk Protocol for HTTP MAC implementation. Check this out : https://github.com/webapibook/hawknet for an example.
For OAuth2 framework and a extensible solution, check out Thinktecture.IdentityServer3 on GitHub
For a lightweight .net 4.5 Web API Tokenization solution, check out Thinktecture.IdentityServer2 on GitHub.
Hope it helps.
We are building an application with following attributes:
Consists of a web app, a web API, and mobile apps in future
The web app will contain HTML pages (multiple features that behave
like single pages applications)
The web app will talk to the web API (communicates in JSON, using
JQuery AJAX Calls)
The web app + web API do not follow the standard MVC architecture
Need to support SSO (will be using client Identity Provider) and
forms authentication
mobile will be consuming the same web API
My question is around what approach we should follow for securing the application. Two of the approaches that we are contemplating on are:
Securing the web API only: the web app is purely HTML and all the
data (that needs security) will come from the web API
For this, we thought of using OAuth for securing the web API
Both, the web app and the mobile app will first perform
authentication, generate an access token (follow the OAuth flow)
Securing the web app using forms authentication/SSO, and using HMAC
authentication for authenticating the API consumer (web/mobile app)
This delegates the user authentication to the consumers (web and
mobile app)
The API consumers will use HMAC for authenticating themselves
How can we pass the authenticated user details to the web API? Don’t
want to pass it as a parameter in API calls
Or is there any other approach that is better than the ones we evaluated above? Has anyone handled a similar situation where an HTML web app uses a Web API, and authentication happens using SSO + Forms/custom authentication?
If you have any comments agreeing/disagreeing the two approaches, that would be welcome as well.
We understand that the web app cannot be purely HTML, and some of the SSO authentication part will have to be handled on the server side and that is ok. But the core application will be HTML + Web API.
Here is some additional information related to this:
- Using ASP.Net with Framework 4.0 (with VS2010 IDE)
- Using Web API 1, but open to switch to Web API 2
You may benefit from building an external authentication/authorization identity management component in your architecture. Your current use cases can probably be covered by the tools that come with ASP.NET, but the architecture will be hard to extend as you start adding different types of clients and SSO scenarios. Look at this and this articles for a more detailed explanation.
Azure ID and Access management offering can be a good option. If you don't want to use the cloud, there are some third party and open source identity servers available.
Here is a good free book to help you understand federated identity concepts in the context of Microsoft technologies.
I am completely new to ADFS. I need to access the ADFS server through node.js. I am searching for good reference notes, with implementation. And suggest me which protocol is best for requesting. Video tutorials are also heplful.
I assume what you want is to authenticate users in AD (via ADFS), for your nodejs based web app. I'd recommend looking first at passport.js.
ADFS supports 2 protocols for web sites: WS-Federation or SAML-P. WS-Fed might be simpler. We open sourced the strategy for WS-Fed and SAML that we use in our product. A strategy is essentially a plug-in for passport.
That strategy should give you a good start.
ADFS v3.0 exposes OAuth2. *
You could use Passport.js with OAuth support or Kong with OAuth support.
You could go the ADFS 2016 OpenId Connect route for ease of implementation (passport.js, only a feature request for kong).
If you're going the Azure route, there's one (passport-azure-ad by the Windows Azure team) specifically for that.
It includes OpenID Connect, WS-Federation, and SAML-P authentication and authorization.
Otherwise, versions disallowing etc., I recommend Eugenio Pace's answer.
Then, check these, is a complete solution (not a video tut)
Using Active Directory Federation Services to Authenticate / Authorize Node.js Apps in Windows Azure
http://seroter.wordpress.com/2013/04/22/using-active-directory-federation-services-to-authenticate-authorize-node-js-apps-in-windows-azure/
pretty fresh tut. (2013/04/22)