I've created an API and deployed to Azure (be patient I'm new to all this). The API will be used by a single daemon app in another organisation. I'm planning to secure this by:
IP White List - this seems to work an to my mind makes the API pretty damn secure.
Client secret create by AAD - is this sufficient?
HTTPs - I've turned this on (Azure APP service TLS blade). However it just seems to work which always makes me suspicious, do I need to link a certificate? Is the encryption being handled behind the scenes?
If it's sufficient or not depends on your scenario. (e.g. is it hipaa / pci compliance?)
I would also add a Azure Key Vault for storing the secrets; WAF (Web Application Firewall) in front of the API + API Gateway (using API Management).
Your point #2 looks useless to me, you'd better request your client to authenticate against your azure Ad and pass the acquired token to your API. this way you'll know who / when called your service.
#3- Azure gives you a SSL certificate, but if you plain to use your custom domain (recommended), you could either generate a certificate using Let's Encrypt or buy from another trusted authority. The encryption happens at rest and in transit, but you could also use your encryption keys for the encryption at rest part.
Related
I'm building a web API to allow some of our systems to raise incidents in our incident management system. I am fronting an AWS API Gateway for this purpose. I want to ensure the API calls are authenticated and require a valid IAM user. I am comfortable with C# / .NET Core, and have read up on using signature v4 to sign the requests. What I can't work out and need help with, is whether the client has to actually sign the requests themselves in the JSON payload being passed to the API Gateway, or whether they can pass the IAM access and secret key only, and then I do the coding to sign the request? I'm concerned that the third party systems won't have the developer knowledge required to sign the requests. They could pass in the IAM user and secret key easily enough, but not sure if they can actually do the signing themselves.
I have to create a WCF service that will receive a request with SAML assertion. Internally it needs to get the Windows user (caller user) and then impersonate the next call to an application. This application only supports AD users.
I tried to get a solution but in most cases I got the solution using Azure Service bus and ACS, but in my case I do not have that. My SAML is directly passed to the WCF service (exposed over internet) and this needs to validate the token, get the windows user and then proceed with the next steps using the impersonation of that user.
My ADFS is set up with a Relaying Party (that my middle ware on cloud already is using to authenticate the user).
My questions are:
Do I need to set up a trust with ADFS and WCF service? Are there any
links for that?
The SAML encryption is all encrypted. For decrypting this at y WCF do I need the same certificate which was used during ADFS setup?
Can I use the same relaying party that my middle ware uses in the setting up the trust between my WCF service and ADFS?
Any links that provide a solution would be helpful.
The diagram flow is as shown in the picture:
You can't use WCF to Azure (unless by Azure you mean a VM in Azure). It's all web API.
WCF goes straight to ADFS. This is the WS-Fed active profile e.g. this.
If the SAML token is encrypted in ADFS, it means the RP owns the private key. ADFS (in the RP encryption tab) only has the public key.
Yes, you need a separate ADFS RP for this.
We are using Web API 2.0 to serve clients in a context where SSL can't be used (no public internet access, clients can't be expected to trust a self-signed certificate). To secure content moving between the client and server, we'd like to be able to encrypt it. We're OK with un-encrypted HTTP headers (only need to encrypt payload). The question is: is there a way to insert a custom handler into both the request and response message pipelines so that we can apply a decryption as a request pre-processing step and an encryption as a response post-processing step?
We are using the built-in features of Web API to serialize/de-serialize between JSON and model classes, and don't want to have to refactor any of that existing code. So an encryption handler would have to be inserted at the very start/end of the request/response pipeline. Is this possible, and if so, what is the technique to insert custom request/response content pre/post processing?
The network is "public" in that users bring their own devices, but the network is isolated from the public internet. Clients will only use a custom application we are developing to consume our Web API service, so we can address implementation issues of a custom encryption scheme on both client and server side.
If you control the client application, you can hard-code the SSL certificate that the server is expected to return, which means that it doesn't have to validate through the normal PKI means (sometimes called certificate pinning). Most other approach will result in you attempting to re-invent SSL, but with some fatal flaw.
To be explicit, I think you are seeing a conflict between "a context where SSL can't be used (no public internet access, clients can't be expected to trust a self-signed certificate)" and "Clients will only use a custom application we are developing" where one doesn't necessarily exist. The user doesn't have to know that the certificate is self-signed, and self-signed does not always imply untrusted.
I want to send data from my C# Windows 8 App to a PHP Script on my webserver to save Highscores etc.
But to avoid Manual insertions of fictional highscore values, I think I have to en- and decrypt it.
In which way can I encrypt data in C# which I can decrypt in PHP and maybe in the other way?
Or are there other Solutions to realize it?
Standard way to encrypt/decrypt data web-transmitted data is using the HTTPS protocol. All encryption/decryption happens automatically once the client and server authenticate and trust each other after exchanging certificates.
To avoid fake data talk only to authenticated clients that are authorized to insert the scores.
So you'd have a list of trusted clients, talk to them over HTTPS and each session would start by authentication (client would prove its identity to your server).
In my opinion the key terms you should definitely take into consideration are HTTPS (SSL Certificate), REST, OAuth
You may want to start by reading the
Open Web Application Security Project (OWASP) - Authentication Cheat Sheet
After that you may find useful some followup technical questions like:
https://security.stackexchange.com/questions/3605/certificate-based-authentication-vs-username-and-password-authentication
How to build a secure and RESTful service in PHP?
Simple PHP REST server with secure user authentication and registered third party applications
...?
I need to find a way to authenticate/authorize users in a WCF-service. I'm using an external authentication service which stores the credentials of the users.
Eg. "Bob uses our loginmethod, we send the credentials to the authentication service, the service lets us know if these credentials are correct."
If Bob sends another request, we need to know if Bob is already authenticated.
Now a session is being created on the client, but it needs to move to the server-side. We can not rely on clients for security.
Can this be solved by using security cookies or do any of you have a better suggestion?
EDIT! I can only use the authentication server and do not have access to it
The problem you are describing is a well-known one that had (at least) two standardized solutions.
Federation using WS-Trust
The first option is a SOAP based one that uses active federation based on WS-Trust. In this solution:
Your client provides credentials to the authentication service
If the credentials are valid, the authentication service returns a signed (and encrypted) token to the client. It is encrypted so that any information contained in the token remains confidential - even the client cannot read it. It is encrypted with a public key belonging to the your WCF service. It is signed with a private key belonging to the authentication service.
The client submits the signed/encrypted token to your WCF service. The service can decrypt it because it holds the private key for decryption. It can trust it because it is signed by the authentication service.
Based on the content of the decrypted token, the service can establish the client identity and make an authorization decision.
In this model, the usual terminology is:
Your authentication service the Security Token Service
Your WCF service is the Relying Party
your client is the Client
This sounds complex, but it is very well supported in .Net and WCF using Windows Identity Foundation. There are many samples available much of it (maybe all) can be done via WCF configuration rather than code.
This is well suited to scenarios where the clients are crypto-capable (like your .Net clients) and where good frameworks exist (like WIF). It is not so good for low spec clients such as browsers and some phones, or where you are not in control of the clients.
It is commonly used in enterprise scenarios, including enterprise-to-enterprise federation. It is used less often in internet scenarios.
the strengths of it are
It is standardised and therefore generally well supported by frameworks
It means that your WCF service never has to handle the client credentials (= more secure)
It makes it pretty easy to switch to different authentication services (because it is standardised). For example, on-premise AD and Windows Azure AD both support this, as do other independent identity services
An overview can be found here:
http://msdn.microsoft.com/en-us/magazine/ee335707.aspx
And Google will show you lots more walkthroughs and examples.
Federation using OAUth 2
In this solution:
The client displays some UI provided by the authentication service (generally a web page)
The user enters their credentials in that UI and the authentication service authenticates and eventually returns a token to the client. The nature of the token is not standardised, nor is whether it is encrypted. Generally it will be at least signed.
The client submits the token with each request to the WCF service
The WCF service authenticates the token as in the previous solution
In the OAuth terminology:
Your authentication service is the Authorization Server
Your WCF service is the Resource Owner
Your client is the Client
Again, this sounds complex, but it is reasonably well supported in .Net. Probably not as well as the WS-Trust approach though at the moment. It is supported by Windows Azure AD and on the client side, using the Windows Azure Authentication Library. May other services use this approach - e.g. Facebook.
This works well where
Your client is low spec or not crypto-capable (e.g. a browser or some phones)
You do not control the client (e.g. a third party application is accessing your service)
It is very commonly used in internet application where you as an owner of the WCF service don't necessarily know the users or the clients. It is a less complete standard in some ways (e.g. it does not define exactly how the authentication happens) and as a result, it is less easy to switch to alternative authorisation servers.
The strengths of it are:
It is simpler and therefore has wider platform support
It is growing in popularity and therefore the library support is getting better all the time
The user never enters their credentials into your UI, only into the auth server, so it is more likely to be trusted (in internet scenarios)
It has a built in way of controlling the scope of the permissions granted to the client, and revoking those permissions, so again it is more trusted in an internet scenario
The official .Net support for this is in the Windows Azure AD Authentication library
http://msdn.microsoft.com/en-us/library/windowsazure/jj573266.aspx
There are other, open source components too, such as DotNetOpenAuth
http://dotnetopenauth.net/
Which solution would be best for you depends mainly on the nature of your authentication service I would say. And on whether you are in an enterprise or internet scenario. If the auth. service could be easily adapted to be a WS-Trust Secure Token Service (STS), then that would be a good route. If adding some web UI to the auth. service is feasible, the OAuth might be better.
Or, if neither option is feasible, you could just borrow the patterns form one approach and use that without going for the full standard.
Good luck!