sharing keys across owin self hosted processes - oauth

I'm trying to create a token server for a few selfhosted owin services (console applications)
However, this seems like its only possible if I host in IIS:
The data format used to protect the information contained in the access token. If not provided by the application the default data protection provider depends on the host server. The SystemWeb host on IIS will use ASP.NET machine key data protection, and HttpListener and other self-hosted servers will use DPAPI data protection. If a different access token provider or format is assigned, a compatible instance must be assigned to the OAuthBearerAuthenticationOptions.AccessTokenProvider or OAuthBearerAuthenticationOptions.AccessTokenFormat property of the resource server. - MSDN
Is there any way to share keys across servers if I'm self hosting by sharing some kind of key in the app.config like how I can share a machine key via web.config? If not, that would mean the only option left is to implement my own AccessTokenProvider (assuming I still use the built in OAuth server and self host)?

I've found this answer, which gives an idea on how you can use machine key in self-hosted OWIN app. Please note that a reference to System.Web is required.
After adding MachineKeyProtectionProvider and MachineKeyDataProtector, I just add the protection provider as below.
//...
app.SetDataProtectionProvider(new MachineKeyProtectionProvider());
app.UseOAuthBearerAuthentication(new OAuthBearerAuthenticationOptions
{
AuthenticationMode = AuthenticationMode.Active
});
app.UseWebApi(config);
The difficult moment for me here was that the order of initialization matters: UseWebApi should come after SetDataProtectionProvider

I've tried MachineKey protection to no avail under Self-Hosted Web API. What finally worked for me is to specify a DPAPI Protection Provider in both projects:
app.SetDataProtectionProvider(new DpapiDataProtectionProvider("myApp"));
HTH

Related

Diffrences of using SSL rather than Validation Key in Asp.net MVC Applications

For each Asp.net MVC application we use Static or Dynamic Key to Validate user Requests/Responses for example in web.config file we may use this due to have static validation :
<machineKey validationKey="AC7308C5274D969E665AC7BED7A863582B571D97D9ED03B314952BD3DD159CDFC164E2341D44BDE8F0284FA924052817B3D7429433AABC3F53A118BB7B3F9ABB" decryptionKey="1EDB4490EC0074F7FF3099D450D5E92F1D39F577F9799D14033D1B27DB0F7A93B" validation="SHA1" decryption="AES" />
At the other hand we have a tool, named SSL (Secure Socket Layer) to upgrade Web App security. SSL also have non repudiation mechanism.
With this in mind, My Question is :
What differences exist between
them? And What types of jobs are related to them? Each one Will secure
which part of App? In other words: Can we be confident from our app by using MVC ValidationKey instead of using SSL?
The concept that baffles me is : They have both Encryption/Decryption.
The very high level answer is that they protect different things. They're complementary; secure ASP.NET applications use both of them at the same time.
SSL is used to protect the client and the server from an untrusted third party. It provides authentication: the client knows the identity of the server he is talking to. It also provides integrity protection: the client knows the page he's getting actually came from the server instead of an attacker. And it provides confidentiality: nobody can read the credit card number the client sends to the server during checkout.
The <machineKey> element, on the other hand, protects the server from a malicious client. Consider that your server sends me a login cookie that says "levi". What if I change the cookie contents to instead read "amir"? The <machineKey> cryptographic services allow the server to verify that when information like cookies and form fields (__VIEWSTATE, for instance) are round-tripped from server -> client -> server, the client hasn't tampered with the payload in a malicious fashion.

Inter web application communication with ASP.NET MVC and CAS

We have implemented several intranet web applications in my company. They all:
are built by ASP.NET MVC 3
use CAS(ticket in cookie policy) and a shared LADP server to single sign on
have role based access control logic according to current logon user
expose many RESTful(like) web apis for page's ajax usage
Now we find those web apis for ajax requests can be used as services for other web applications(like employee info, client info etc). Which means we need to access those apis at backend(with C# code). The problem is the authentication and authorization.
I don't know how to go with the existing authentication mode to access those web apis. I can only think of a way that use an shared service credential among back end servers but it means this credential must have a full access authority. Is it a security risk? And as I metioned, we use ticket in cookie policy with CAS. Which is OK for browser but seems difficult for C# code. How to use a credential with CAS from backend? Use a WebClient and handle 302 manually?
Has anyone met a similar case and have some good experiences with this? Please give me some advice. Thanks a lot.
What you need here is to use the CAS proxy mode to access backend web services : https://wiki.jasig.org/display/CAS/Proxy+CAS+Walkthrough.

WIF - Federated Provider with multiple Identity Providers - store IP info in db?

So despite the warnings, I think I need to build a custom STS. We will support an arbitrary number of customers who provide identity information via SAML.
What is the best practice to store details on each IP? Most examples seem to store this info in the STS's web.config. That seems like it wouldn't scale real well.
Is there an obvious reason not to just store this stuff in a db and load it when the requests come in?
Fundamentally, if the Identity Providers will change over time, such as via some online administration function, rather than a new application deployment, it makes total sense to store the information in a database (or other Storage).
I think this is a potential issue for any multi-tenanted service that is federating identity with the customer.
ADFS v2.0 (which is Microsoft's STS product) stores its details in either a SQL Server DB (or SQL Server DB farm) or a Windows Internal DB. So if it's good enough for Microsoft ...

Service to Service authentication , service identity and access rights management

I am currently developing a distributed application using Ruby, Ruby on Rails, Sinatra and pure Rack web services.
I will have few services (RESTful , not SOAP based) which will communicate using JSON and I would need a way to secure and verify the identity of each of those services during the communication between them, so no one could pretend to be a service and make requests to the other services.
The core idea is to treat other services as "users" and be able to verify their identity and limit their access to data if necessary.
So the question is how to do this using only Ruby and how to manage effectively the service identities and their access rights.
Should I build some additional authentication service usable by the services ?
Should I build internal gems to provide some connection middleware with keys/shared secrets ?
Is there maybe some other way to do this?
I would generate an application id and secret that you could pass with each request. Since you are not dealing with other users and just applications try looking into authentication tokens with devise.
I think OAuth is a protocol that is commonly used for web service - to - web service runtime authentication, especially with RESTful APIs.

Securing REST and JSON

I want to build my web services serving JSON data utilizing RESTful architecture.
But I want my own client apps only that can request from my web services.
Basically, my web services contain sensitive data that is not for public consumption, but I wanted to build it that way so I can build many different client apps that connects to my web service.
Would appreciate any ideas for this, thanks.
The fact that it's RESTful or uses JSON isn't a relevant factor when it comes to securing a web service. Any web service would need to be secured in the same manner. There are a few things you should do:
If possible, don't host your web service on the Internet. If the web service is hosted within your company's LAN, for example, it won't be exposed to public consumption unless you specifically exposed it through your router.
Set up authentication and authorization rules. If you're hosting your web service inside of a Windows domain, you could simply use Windows authentication and set up rules based on Active Directory users and groups. Other options are to use HTTP authentication, client certificate authentication, or if you're developing in .NET, forms authentication.
Use encryption (HTTPS), especially if your web site is hosted on the Internet.
You just need a couple things in place to do this. First, the service client will need to authenticate against your service (over HTTPS) to make a request. Once the client is authenticated, you can return a private token which the client has to include with this token. As long as the token expires after a reasonable amount of time, and a secure algorithm is used to generate it, this should do what you want.
If you have more strict security requirements, you can follow Jakob's suggestion, or have the client start a VPN session prior to making requests.

Resources