In investigating federated authentication, I've been running into a protocol alongside SAML: HTTP-FED.
Curiously, I can't find any technical documentation for this protocol.
What is it? Is it, like I suspect, a claims-based protocol for use with HTTP instead of WS- services?
HTTP-Fed appears to be a creation of a commercial vendor (Symplified). It has not been ratified by any standards bodies (that I've found) which is why you probably can't find much on it. From what I've read on their website, it appears to essentially be a fancy name for credential caching/credential replay across the internet. From their site -- http://www.symplified.com/http-federation/
"... HTTP-FED leverages the existing HTTP login mechanism at the SP.
The implication of this is that no changes to the SP (destination
application) are required and no special software is needed by SPs,
thereby reducing the effort required to federate domains."
It's not a standard so there's no info on how you'd implement it outside of buying their product. If you're looking at Web SSO for Cloud Applications, I'd stick with actual standards (SAML, OpenID, OAuth, Open ID Connect) that are designed with security in mind for this type of activity.
Related
Imagine the following situation. I have an API and a developer builds an application that retrieves new content from it on a daily base. She stores this content and provides this data to all the instances of an app she developed. In this way these apps do not have to call the API directly.
Is there a way to prevent this and force the apps (and therefore the end users) to use the API and not only the application on the server.
I found many questions about how to cache API data but not how to prevent that. I am fairly new to this, so maybe I am overlooking something or maybe it is not possible to prevent this.
Thank you in advance!
Assuming you are using Apigee for API-management, you have some options. First, consider the options available to you contractually, if this is that sort of business relationship and you can impose certain API behavior with a business partner through a contract.
Separate from the legal side of things, we remember that you control your API and the credentials you issue for use by your API clients. You cannot though control, practically, what a client developer does with the credentials you issue: she could promise to embed the credentials in the mobile apps' API client, but change her mind and use it centrally, and then design her mobile client to call into her central cache. If though you really insist that only mobile app clients should be calling your API and not a hub/cache server, then you could consider applying constraint policies on your API (within the Apigee proxy, such as Access Control). For instance, you could blacklist your partner's hub/cache server IP address, although that is weak security at best. Or, you could apply a constraint that only clients with certain identifying User-Agent strings (mobile OS, client) are allowed to connect to your API. Or use GeoIP filtering to allow only clients from certain regions, if that applies to your use-case.
Finally, depending on the data model, you might be able to rate-limit such that a bulk cache becomes impractical: if your edge-client use-cases is to fetch a single record, but a cache would have to hold thousands of records, then you could impose a per-client rate limit (Quota policy) which is no bother to individual mobile clients, but makes the work of a hub/cache server untenable.
I'm evaluating various hosting options for ASP.NET Core application.
In the new programming model of ASP.NET you process a request with a set of middlewares (which are mixture of older IHttpModule & IHttpHandler).
You can have a middleware which can be responsible for authentication, handling of static files or compressing the response before sending (just to name some).
Here comes the confusion.
Where to set a border between server and an app in context of responsibility?
Which side should be responsible for compressing the response? With IIS this was handled by the server and configured in web.config. Kestrel doesn't provide this functionality AFAIK, so you need to implement a custom middleware in the app which will handle this for you. Which one is more appropriate?
What about authentication? IIS provides settings for authentication (anonymous, impersonation, forms auth). On the opposite, in ASP.NET Core we can also write an app middleware which can handle this for us.
Ok, SSL is handled by server, because it's below in the protocol layer and app operates on HTTP(S) only.
What responsibilities should server have? What responsibilities should an app have?
The server is responsible for implementing the base HTTP protocol, managing connections, etc.. It may also choose to offer other features (e.g. windows auth), but we recommend against it unless it can provide a distinct advantage over a middleware implementation. E.g. Windows auth could be implemented in middleware, but it would be much more difficult due to some of the connection management constraints. Compression could be implemented in middleware just as easily as in the server.
As stated on wikipedia:
"The primary function of a web server is to store, process and deliver
web pages to clients"
The thing is that all famous http servers (nginx, apache, IIS, ...) come with a lot of modules that can handle lots of different tasks including the ones you mentioned in your question (authentication, compression, ...).
It's quite likely that the more modules you'll add the slowest your http server will be. IIS for instance is, by far, not known to be the fastest http server around, but if you remove all the modules and use it just for serving resources, then it will become really fast because this what it has been built for back in the days!
The problem of responsibility goes the same with all kind of software application.
Think about databases whose main role is to store data. RDBMS like Oracle or SQL Server are pretty good at it. But as soon as they release a new version, they also release a new functionality that has nothing to do with storing data. And people use it! ;-)
How many times people used their DB as a search engine? I saw people sending mails with SQL Server! But the worse was some guys trying to call webservices within store procedures ;-)
It's always tempting to have one tool to do everything but you need to keep in mind that it has not been built for every purpose. I'd rather use a bunch of lightweight tools that have one single responsibility and that handle it correctly instead.
Now back to your question, I think it's a good approach to make use of middlewares. That way you have control on the entire pipeline and you know exactly what your request have been through. Middlewares are also testable! Getting rid of all the unnecessary modules will definitely lead you to a more lightweight http server.
The righteous "it depends" answer is also acceptable. If you make some tests and realize that gzip compression module is 10x faster than the middleware, go with the module! Don't be dogmatic neither!
I have a product which consists of internal ASP.NET/MVC web sites all using WIF to enable SSO through a custom STS/IdP service. We now have a new partner site hosted outside our network on another domain and would like to enable SSO for users as they navigate between the sites. The new site uses different technologies (e.g. python) but we assume we can create a trust relationship using SAML standards as the protocol.
With SAML as the underlying protocol we assume this can be achieved but we cannot find any guidance on patterns for implementation, best practice guidance, etc... Can some recommend some resources on how to establish this type of cross-domain trust?
Note: While other options like OAuth could address this, we would prefer to stick with a SAML-based solution
Does your custom STS/IdP service support SAML?
On the python side, they will need a SAML stack. There's a number around - refer Introduction to OneLogin's SAML Toolkits e.g. There's a good diagram there as well that shows the login flow.
Then you need to get the python SAML metadata and give them your custom STS/IdP SAML metadata.
Import on both sides, configure whatever assertions you need and you should be good to go.
You'll also need to sort out the signing certificates that go into the metadata.
Example of process using simpleSAMLPHP - Configuring the SP
Following provides excellent example of SAML implementation:
http://www.codeproject.com/Articles/56640/Performing-a-SAML-Post-with-C
We used it in our project and it worked fine.
I'm totally new to SAML. I want implement SSO for my ASP.NET Website. I got the SAML assertion from my client. I would like to know what are all other requirements I need to get it from my client and what setup I need to implement at my end.
Can anybody help me out in this.
Thanks in advance.
The first thing that I would do is avoid writing the SAML code yourself. There's plenty out there. #Woloski (above) has some. My company has some (I work for the company that makes PingFederate). There's some open source stuff, too. I've seen good connections from KentorIT authServices. If this is your first foray into SAML, then my bet is that ADFS is way overboard. I'll be honest, the groups we see most commonly at Ping is when they decide to go "all in" with SSO. The first one or two connections are easy. Tehn it becomes a management nightmare rapidly thereafter. The reason I say to avoid writing your own, is because there are a LOT of nuances to SAML, with massive pitfalls, and headaches you just don't need.
As the service provider (SP), you need to tell your client (Identity Provider, or IdP) what "attributes" you need from them to properly connect their users to their account in your application (maybe a username?). In addition, you can ask for additional attributes to ensure their profile is up to date - phone number, email, etc. It's up to the two of you to determine what you need (and what they'll give you). Obviously, they shouldn't send social security number, if you have no need for it.
You also need to decide if you will do SP initiated SSO (will the users get links to documents deep inside your app?), or if just IdP initiated (Or will always just come to the front door?) will suffice. What about Single Logout? Do you (or they) want to do that? [Personally, I suggest NO, but that's a different topic]
What about signing the assertion? Your cert or theirs? If you're doing SP-init, do you need to use their cert or yours for signing the AuthnRequest? Do you need encryption of the assertion, or maybe just a few of the attributes?
Generally, you do all of this with a "metadata exchange". You give them your metadata that says "this is what we need". They import that metadata to build a new connection, fulfilling the attributes your app needs with calls to their LDAP or other user repository, as well as doing authentication (if required). They finish building their connection, and export THEIR metadata, which you import to build your connection (thereby making sure you all agree on certificates). You hook it to your app, and away you go.
I make this sound easy. It is, and it isn't. Rolling your own can mean issues. Lots of them. With some being so minute that it takes pros hours (and days) to see it. When it works, it works, and well.
HTH -- Andy
you can use something like ADFS to accepto SAML Assertions. ADFS gets installed on Windows 2008 or 2012.
You would need to ask your customer
the signing certificate public key and
the sign in URL.
Then you would create a "Claims Provider Trust" in ADFS and enter those details. Then a "Relying Party Trust" that represents your application. Finally you would have to configure your application with ADFS using WIF. This blog post have more details:
http://thedotnethub.blogspot.com.ar/2012/12/adfs-20-by-example-part1-adfs-as-ip-sts.html
Also you can use Auth0 to accomplish the same without setting up any software on your side (disclaimer: I work there).
I am just unsure whether Spring has any mechanism preventing users/malicious bots from spamming for example registration request hundred times on my web app.
Does spring offer this kind of protection under the hood and if does not which direction I am to look? Some magical property in Spring Security?
Also does AWS provide any protection against this kind of brute attack when my application is deployed there?
The short answer to both your questions is no. There is no built-in mechanisms in either Spring or Amazon Web services to prevent this.
You will likely have to provide your own implementation to prevent excessive access to your API.
There are a couple of useful resources that can help:
Jeff Atwood's piece on throttling failed log-in attempts should give you a good starting point on how to implement a good strategy for this.
Spring Security's Authorization architecture is really well designed and you can plug in your own implementations fairly easily. It is well documented too.
There is the official Amazon Web Services documentation for using Security Groups, which again should help you ensure you're running on AWS with least permissions in terms of network access
Finally you could look at a service like Fail2Ban for monitoring log files and blocking malicious requests.
So in short there isn't really a simple ready-to-roll solution, but using the above resources should get you on the road to running something that ensures you're using the best practices possible to prevent malicious attempts to access your system.