really hope that I can get some pointers with this before I go wasting too much time. In truth, I'm not even one hundred percent sure where I need to be asking this. I'm dealing with a whole heap of technologies I've had little to know experience with. Historically, I've been a pretty simple vb.net desktop developer so I'm learning MCV5 & C# as I go. I realize some of this might be in the wrong place, but hoping for pointers at lease
So the situation is I've been asked to develop a web application/api by a number of my customers so that their field staff can perform certain data entry functions while out of the office and periodically feed back into their management systems. All these customer have the very close to the same requirements and management systems, so my my intent is to build a single web application with a multi-tenant database where I control who gets to see what based on their login.
The core of the web app, database(s) etc I've got my head around, in fact that all seems pretty seamless. Using https://msdn.microsoft.com/en-us/library/aa479086.aspx as a start point I think I can manage the database side of things.
Where I'm really struggling over is how best to secure this system. Looking at the options in available to me in visual studio (2015) I think the best option for me is for me to use an On-Premise ADFS. My boss has already put his foot down regarding Azure, so unfortunately not an option, we pretty much have our own server farm in house more than capable of hosting this.
The real sticker here is my SA has pretty much said this is not his problem, if you want ADFS and a web server, you sort it out. He's given me a nice fresh server VM with Win2012R2 at least, but doesn't want anything more to do with it.
So, to the questions
Is ADFS even needed in this scenario, or am I better deal with this
all via a standard AD or some other tooling? And even if it is possible, is it a good idea?
Duringdevelopment/testing, is it ok to use a self signing certificate or
am I going to run into to trouble with certificate errors?
When configuring ADFS, you get asked for the federation Service name. In
the senario above where I'm using it for authenticating a web app,
is it ever exposed directly to the end user? Are they going to be
needing to type this in to their browsers? and will it be better to have external DNS entries for this?
My 2-cent:
There will be a learning curve, but if all the users are stored in AD, using ADFS will give you some advantages such as SSO, federation against other providers if you ever need it later on.
Using self-signed certificates during dev/test is fine. You can turn off certificate revocation check on ADFS side.
No, that Federation service name doesn't get exposed to the end users. I would suggest you have external DNS entries for your ADFS because your users need to access it from the outside. In short, a user rarely needs to type in ADFS url. Instead, he or she needs to access a service provider site and it will redirects he or she to the ADFS site.
This is becoming a more common scenario and can be seamlessly handled with AD FS. Ideally what you would want to do is:
deploy your AD FS farm
Configure your Web Application to trust your ADFS STS
Whenever you need to add a customer who will be using your multi-tenant application, add a federation trust with that customer (i.e. federation trust between your AD FS and the customer's AD FS)
This will ensure that you don't have to deal with identity management for every individual user when you add a customer. When a customer tries to login to your WebApp, then he will be authenticated against his AD FS, and your AD FS will get the token and sign them and present it to the Web Application. This will give them SSO which everyone has started to expect as a de-facto :)
Self signed certificates - As Thuan mentioned it is ok to use them during testing, just ensure that all your test boxes are configured to trust the certificate or otherwise you will be seeing connection drops all around
Federation service name - As explained in the setup summary above, the federation service name will never need to be exposed to the end user from a customer's organization. For all he knows, he is being authenticated against his AD FS as he is used to it already.
You might want to consider deploying AD FS in Azure:
AD FS deployment in Azure
Related
Our SAAS system is currently using standard Microsoft.AspNet.Identity.Owin libraries to authenticate users via Bearer tokens, as well social logins such as Facebook/Google/Twitter/etc.
Some of our users are asking for us to start allowing of authentication via ADFS.
I'm trying to understand how this can be done. Unfortunately, all of the blogs appear to dive right into the details without providing a good overview as to what's involved. Furthermore, most blogs talk about trusting a specific Active Directory, while we need to trust a whole number of possible customers' active directories - and do it dynamically. IE: customer registers for an account using custom username/password, then provides our SAAS application with some information about their AD. Afterwards, our SAAS application should trust authentication for users in that AD (just the auth part)
Can anyone provide information on what's involved?
TIA
Agree with #vibronet's points.
Another approach would be to add STS support to your SaaS application. This could be either WS-Fed or SAML. You have tagged the question with Azure so AAD could be an option.
You could then federate with any number of other STS's (like ADFS). Note as stated that each ADFS has to agree to add your metadata.
Another approach would be to use IDaaS (e.g. Auth0, Okta). These would do the Identity heavy lifting for you and would essentially provide the STS capability.
The question has 2 parts,
how to work with an ADFS instance and
how to deal with an arbitrary number of ADFS instances from different
owners.
The answer to 1) is to use the WS-Federation middleware, which can be added alongside the middlewares you are already using. However the initialization of that middleware requires knowledge of the location of the metadata document of the ADFS you want to target; furthermore, the ADFS administrator must provision your app explicitly or no tokens will be issued. Hence, the flow you are suggesting (temporary username/password and subsequent details exchange) might be tricky - but not impossible.
About 2) there isn't a way of wiring up an arbitrary number of different ADFS instances unless you modify the middleware setting pretty heavily. The actual answer is that the standard practice for dealing with that scenario is to rely on one intermediary ADFS (or equivalent) that can broker trust toward all others, while your app only needs to trust the intermediary ADFS.
I've been scratching my head over this issue for over a week. We have a web app that we would like to implement SSO for. SSO with windows active directories of our clients (i.e. we essentially need to authenticate against our clients' active directories without much trouble)
The only thing I am 100% sure about is that I will needed a security token service that will have to communicate with an Identity Provider. My question:
Which service is most suitable for the above scenario (AD FS? OpenID & OAuth 2.0? SAML 2.0 and shibboleth?)
How will I connect to the active directories of the clients? Maybe I'm not understanding how the STS is to be used, could anyone clarify? I'm working with an Azure Web App
Will there have to be a different IdP for each client? Will the client have to do more than just give us standard information? What would this info be?
...should I be using Windows Identity Foundation?
HELP :( ... this is an SOS
If anyone could clarify at all, I will forever be grateful. I normally upvote anything I find helpful and accept whichever answer is the best so feel free to answer with what you think might be useful in helping me understand how I can achieve what I am after.
These are the three options I know:
As you mention one option is ADFS this solution means that your customers should install and expose Adfs. ADFS means Active directory-Federation Services, so in this case your application needs to speak WS-Fed (not oauth). Typically if the user is inside the LAN adfs uses integrated auth, if not it will prompt credentials.
WAAD is a new service from Azure, it allows companies to expose their directories to use in cloud applications. With this approach your customers need an account in Azure, create a directory and use the dir sync agent. Your application will talk SAMLP with WAAD.
Auth0 is an authentication broker that allows developers to use social but also enterprise identity providers like AD but also google apps, waad, adfs, salesforce, etc. if your customer only has AD you will provide him an msi for a windows service, that will bridge the company AD with your auth0 account, you can have as many AD as you want. Your application speak oauth with Auth0. This agent supports kerberos authentication as well. The following graph explains this solution:
Disclaimer: I work for Auth0.
WIF doesn't support SAML or OAuth.
Your application is in Azure.
Suggest add WIF to the application and then "bind" to Azure Active Directory. In VS 2013, use the "Change Authentication" feature for this.
Make the application multi-tenanted.
Each customer has their own tenant. User DirSync to sync. each customer AD with their AAD tenant. (That gives same sign-on). Adding ADFS to each customer gives single sign-on.
However, the customers will probably push back on this because of perceptions around security.
I'm working on a WCF project that will be our new service layer.
These services will be called by 2 separate clients, the first of which is a WPF application and the other is an ASP.Net web application. The WPF client will be run by internal users and will authenticate with the service via domain authentication and run under the context of that user. The other will be used by external users and needs to authenticate using some separate mechanism then impersonate a "WebUser" account on our domain.
I'm reading a bit about Windows Identity Foundation and it sounds like this might be a good fit. Am I right in thinking I could have 2 token services, one for domain authentication and one for something like ASP.Net membership authentication (Or some similar equivalent) and have each client get it's token from the relevant STS and pass that along to the WCF service?
I'm assuming there is an STS I can use out of the box for domain authentication, but will I have to implement the second one myself to authenticate web users? I can't find a lot of information on this.
Am I thinking along the right lines or should I just be creating duel endpoints for each service each with a different authentication mechanism? Or should I be doing something completely different?
Thanks
The big advantage of using Claims-Based authentication / WIF is that both the task of authenticating the user AND the administration of the user's properties are moved way from the applications to the STS/Identity provider.
You are developing a service layer but the true benefits of using WIF will be for the applications written on top of your layer. The WPF application will no longer need to connect to the AD and fetch the user's groups to figure out what they are allowed to do. The groups will already be visible as claims in the token the user/WIF provides.
The web application (is it just one web application or more?) will no longer need the ASP.Net Membership database with accompanying user administration. This functionality gets moved to the STS.
There is a cost. (There always is, somehow...) Claims-Based authentication has a rather steep learning curve. It takes a while for the quarter to drop for all people involved.
So the answer to your question depends on what kind of users the web application(s?) built upon your service layer have and how many. And how much they wish to know about them. Can you perhaps trust Google / Facebook / Windows Live for authentication? Are the users already in an existing database within your domain? How much work will it take to maintain the user directories? Do your marketing people wish to send them emails regularly? Et cetera.
This is probably not just for the service layer's developers to decide, but something to discuss with people in the rest of your organisation.
If the benefits are not particularly big, the alternative is to simply keep these responsibilities at the web application's server. Each web application will have a good old ASP.Net membership database, it'll authenticate the user all by itself. When asking queries from the service layer, it'll present its web server certificate plus specify the user's name and type.
If the benefits are big enough, you can in principle use ADFS 2.0 for everything. It can also store external users nowadays and it's free if you already have Active Directory. Or the ThinkTecture 2.0 server that Ross recommends. It's easier to customize and perhaps your systems administrators and security folks will not be too enthusiastic about opening the firewall to the ADFS server.
Microsoft has some good reads on WIF, in particular an Overview of Claims-Based Architecture.
You should take a look at identity server as it can indeed handle this scenario.
The person who leads the project above has a great pluralsight video on this exact scenario! You need to sign up to watch it, but they offer a free trial.
Basically you get a token from the identity provider (windows ADFS for the internal client, and what ever you decide for the external users). You will give this token to the federated gateway (identity server probably, but it could be Azure ACS). This will return an authentication token that you can then use with your service.
All,
I'm a little confused over some of the concepts behind Windows Intentity Foundation and the overall architectural fit in a third-party "trusted" environment as regards Authorisation. I think I may have missed something but I can't see how it would work in the real world.
As an example, we have a number of systems behind a portal. Customers can access the portal and, based on their permissions they can access features of each different application. In the current scenario, we may have a single authentication step (user id/password) that passes the authorised identity/principal (against a custom authentication store) to each application. The application then uses this pre-authenticated identity to look up against its own roles to allow users access to certain features.
This is all managed internally - i.e. each application understands its own roles so each application has its own admin function that maps a user to a role.
Ok, so it works but is a pain to manage and our customer has to remember our portal user id and password.
I'd like to move to a trusted environment so that we trust the token from their STS and authentication is all hidden. However, I simply cannot see how Authorisation will work - we're asking that each third party implement roles in their STS to pass along with the token. We've shifted the admin to them which may break their security models anyway.
So we cannot delegate authorisation to them, and still need to manage the map of a trusted token to the roles the application requires.
So the great benefit of trusted STS, whereby user A leaves trusted company 123 and user B joins to take over, and they don't have to wait for us to make any changes..... just isn't practical in the real world.
Which is a shame, as I really like the idea.
Have I missed something fundamental?
To answer my own question, I spoke to a Microsoft architect about this and he broadly agreed. You can create rules to map third party data to the properties your app needs, but if the third party is not prepared to change their systems (e.g. Active Directory) then you're stuck.
Therefore, IMO the chance of a third party agreeing to add new properties to their AD domain to support your app is minimal, it leaves a pretty big hole in the ethos underpinning WIF and trusted STS.
I have a need to implement a STS-IP server for our web applications and services. The server will need to issue SAML tokens for the following scenarios:
Business partner submits their SAML token which is converted to a SAML token with the claims required for our applications. This token is used to access our Web Applications and Services.
Our public facing applications need to have a user sign in (via forms authentication) and then access our web applications and services with a SAML token.
Our clients (without a STS trust) needs to authenticate with our STS-IP server, get a SAML token, and use that token to access our WCF services.
In all 3 scenarios, we need to have custom claims on the SAML token that our applications and services use. The thought is once we identify the user, we would look up their authorization in our back-end systems and attach claims.
In these scenarios, you can assume the back-end authentication store is a custom implementation with authentication stored in Active Directory and authorization stored in a database.
So my thought has been, we need to create a custom STS-IP server using something like Windows Identity Framework. But I have also been reading that you should not do this because it can take some time.
Can I use an off-the-shelf STS-IP server? Everything I've seen is a mapping between one system to another (SAML to SAML or AD to SAML).
Why will it "take a long time" to build a production ready STS-IP ? I built one using WIF very easily, but I guess I don't understand the risks in doing this.
In terms of "It will take a long time", the documentation showing how to do this is very poor. See here: http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/257d93be-165e-45a6-a277-fc7ed2286e7d/
Anyhow, you'll simply need to look over the code samples that Microsoft provides: Google for Identity Developer Training Kit. That should help you get started.
Why are you not considering using ADFS? If the backing store for authentication is AD, then ADFS is probably a good candidate to evaluate.
Before writing you own STS, you may want to check out this blog and closely review the features that you may need in the STS. Just because you can build one yourself, doesn't always mean you should.
extending adfs to multiple identity and attribute stores
They "why not" is relatively simple: Why take weeks to build something that will probably only handle a single use-case when you can put in off-the-shelf STS in a day that will cover all sorts of things your company may come up with? Building it yourself will also require you to become an expert in SAML (which is probably not the best us of your company's time).
Check out --
http://www.pingidentity.com/our-solutions/pingfederate.cfm
Good luck -- Ian
Agree with #eugenio - why not use ADFS?
ADFS can only authenticate against AD as discussed but it can derive authorisation attributes from AD / LDAP / SQL server
The nuts and bolts for an STS are available in VS 2010 plus the identity tool kits. A simple STS can be quickly prototyped.
There are some examples available. StarterSTS is already mentioned plus SelfSTS.
The hard part is getting the security right especially if this will be part of a production system. As per "Steve on Security" Build your own Directory Federation Service:
It may sound like I think it’ll be a
synch to develop this system and have
it work securely, but in reality there
is a lot that will need to go into it
to protect the network, the employees,
and the data this could possibly
interact with. It is tough to develop
applications securely. It is far
harder to develop secure applications
whose sole responsibility is security
related.
That's the reason that all the samples on the Internet have disclaimers in bold:
Do not use in a Production environment