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.
Related
We have a native Windows desktop app that uses resources that we control on behalf of our customers. In the vein of not rolling our security infrastructure I am wondering if it makes sense to use an OAuth library / framework like IdentityServer (our frontend and backend stacks are .NET based with ASP.NET Core on the backend).
But from what I have read OAuth is all about giving an application access to resources that the users owns that are managed and controlled by another party without exposing the user's security credentials to the application.
Given the application is from our point of view "trusted" it seems more straight forward for the application to capture the password directly from the user and obtain an access token (e.g. bearer token) from directly from the back end rather then redirecting the user to the web browser.
Management of authorization levels for various resources is something we need to take care of robustly, as we will have multiple applications and users which will need configurable access levels to different types of resources, so I don't really want to be rolling our own solution for this.
We also want the ability for users to remain logged for indefinite periods of time but to be able to revoke their access via a configuration change on the back end.
Should we be using a different type of framework to help ensure our implementation is sound from a security point of view? If so please any suggestions of suitable technology options would be most helpful.
Alternatively, is there a OAuth flow that makes sense in this case?
It sounds like the "Resource Owner Password Credentials Grant" might help with your problem.
In the short term, the use of oauth may not seem very different from the normally "username password + rbac" based model, but the benefits may come in terms of scalability later on, for example when single sign-on needs to be implemented, or when it comes to the need to provide service interfaces to third parties.
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
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 am in need of advice on how best to tackle the following scenario and best practices to implement it.
Our company wants to overhaul its old IT systems and create new website app(s) and possibly mobile apps down the line for its employees and contractors to interact with.
So i was thinking about creating an api that both the website apps and mobile apps could be created from...
https://api.company.com/v1
The advice i need is in relation to security/authorization of the api. My thoughts at present in how to implement this would be that the employees/contractors would interact with the api through the companys website app(s)/mobile apps which would then communicate with the api and set the appropriate access permissions
WebsiteApp.company.com ->>> api.company.com/v1
mobileapp ->>> api.company.com/v1
First thoughts is just setting up a username and password for each user on the api side and let both the websiteapps and mobile apps use this. The problem however is that the contractors and possible some employees cannot be fully trusted and could pass on username and passwords to third parties without the company's permission. So my question is really what other security/authorization/authentication strategies should i be looking at to overcome this situation. In a perfect world each user would have to authorize each device/mobileapp/websiteapp he/she wants to access the api from...
Is OAuth 2.0 capable of this?, not sure if its capable of specific user/device/website scenario though ?
Technologies thinking of using are:-
API
Node.js with (Express js? or Restify?) , MongoDb
Consumer Apps
Website Apps (Angular Js, Backbone etc..)
Mobile Apps (PhoneGap, Jquery Mobile etc..)
Many Thanks
Jonathan
It seems that your main concern is that you can't trust the people you are giving access to, and if this is the case, you probably shouldn't be trying to give them access in the first place. If these apps are to be used for any confidential information or intellectual property that you are worried about someone else seeing if the contractor/employee gives away their password, then you have to consider the contractor/employee just taking the information and giving it away.
In this situation your username/password should suffice for authentication, however you should also consider very tight permissions on who can access what. If you are worried about information getting out, everything should be shown on a need-to-know basis. If a contractor doesn't need a specific piece of information, make sure it isn't provided to his account.
You could also consider tracking the locations (IPs) that an account is being accessed from. Perhaps when an account is accessed from a new location have the employee/contractor complete some task to validate the account; which could be anything from entering a validation code (similar to a two-factor authentication), to calling a help-line and having the location authorized.
This might be a bit late, but as i am going through the same process (What is the correct flow when using oAuth with the Resource Owners Passwords Credentials Grant)
We have not figured out the core implementation what you want to do sounds similar to what we are trying to do for our service.
From my understanding it depends on the apps and if they are trusted or not and what you plan to do with your API moving forwards. If the apps are trusted you could potentially use HTTP-Basic over SSL which is a viable solution.
For us, we are going to create a suite of trusted official apps (Web, Mobile etc) via the API and then open it up, so we are deciding to go through the pain of oAuth2 where for our apps we will use the Resource Owners Passwords Credentials Grant type where you swap a users user name and password for a token which is what the client will use to interact with your API with the trust implicitly defined.
When we open up the API for 3rd party consumption this model wont work and we will go through the processes that all the major sites do and get explicit permission from the user on what the 3rd party apps can do with their data.
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