I'm kinda new in the mobile world and wcf world.
I have develop a mobile app that communicates with a WCF service.
What security topics should I look into?
I do not know much about security either ... usually you try to secure the channel? the messages being sent?
When you decide security you usually deals with following terms:
Confidentiality - ensures that only supposed recipient can read and understand the message
Integrity - ensures that message cannot be changed during transmission
Authentication - ensures that only callers with allowed identity can use the service
Autorization - ensures that only callers with exact claim are allowed to call given method
Authorization is always handled in code. Confidentiality, integrity and authentication can be handled on message level, transport level or mixed mode. Based on some very small knowledge about CF I suggest you should be able to use transport security = HTTPS to provide integrity, confidentiality and also Basic HTTP authentication. CF should also allow using message security secured by certificates (also provides integrity, confidentiality and authentication).
MSDN contains example for creating service and CF client secured by HTTPS with client certificate (used for authentication).
Related
I'm developing the authentication/authorization architecture for several APIs.
I'm using IdentityServer4 as a Security Token Service (STS).
From what I've read from "Dominick Baier" (one of the persons that built IdentitySever4), there are only two types of Flows that should be used:
Client Credentials Flow. (machine-to-machine)
Authorization Code Flow + PCKE. (for iteractive users).
I have several C# Web API's that will communicate with each (Machine-To-Machine), and I will use the Client Credentials Flow.
But then there are some WPF Desktop Applications, that will need to access some APIs, and don't have a user.
Which flow should be used?
I've read that:
Desktop/Native & Mobile Applications should use Authorization with Authorization Code Flow (with Public Client and PKCE), since they are hosted on the Client side, and the Client/Secret is can be leaked (maybe on a Desktop application we can Encrypt the Secret? But then will need to manage a way how to store the secret that decrypts that right?)
Then I've read:
"Anytime you have a system that isn’t concerned with the end-user identity (and just needs to authenticate the system), use the OAuth2 Client Credential Grant."
For now, this is my case, I'm not concerned with the end-user identity (but maybe in a near future I will).
So since the above points conflict with each other:
- Which flow should I use?
- Can I have a Desktop Client using Clients Credential Flow and be safe?
Also, I've read a bit about Mutual TLS, If I use that, does this change which flow should I use?
You can't trust a client because you can't be sure a request originates from the client. And another problem is that clients are not good in keeping secrets. But there are different types of clients.
Clients that run on servers often having a single task, like synchronizing data which is user independent, are suitable to use the client credentials flow. To some degree they can keep a secret (running on a server).
You can use unique credentials for each instance but that doesn't make it safer. It helps you to identify the client, but doesn't add security. Security is about monitoring behaviour and detecting anomalies. Or perhaps narrowing access by filtering on ip address.
But you are not limited to use the two flows you've mentioned. Being a token provider, you can extend IdentityServer with custom flows using extension grants.
Without user the client credentials are somewhat similar to the resource owner password credentials (ROPC) flow (another option that is no longer covered in the grant type documentation but still exists, see the old docs). Neither are really safe in the sense that both can be automated. The user factor can be eliminated since user interaction isn't required for these flows.
But I wonder why your app has no user, running on a user machine. Because ideally you have a client (without secret) where the user logs in and let the client contact the api (delegation).
So there are two things: do you need to identify the client? If not you could suffice with an ApiKey, like e.g. Sendgrid. And you can never trust a client. Security has to be server side.
So basically it doesn't really matter, there is nothing you can do to make it much safer client side. The only thing you can do is add the requirement of user interaction. So perhaps now you don't need it, but it will increase security and allows you to delegate api access to the client.
I have a c# .net wcf web service on a windows server with iis. I need to know if there is a way to tell the web service that it can accept request only from specific URL.
example:
ApplicationA call ApplicationAwebService = should work
ApplicationB call ApplicationAwebService = should be denied
Right now, they are all on the same server, but I need a solution that works even if they are on a different server (3tier applications).
thanks
If you are using WCF then its possible to use mutual authentication between services and clients. Mutual authentication achieves not only security for the server to accept connections from legit clients but provides the ability for the clients to verify that they are talking to a legit server.
Mutual authentication can be achieved through Message security (Encrypting the data sent between the client and server and vice versa) by using certificates, kerberos (Windows auth), tokens and a username/password configuration.
Mutual authentication can also be achieved in WCF through rolebased authentication, identities, and resource based authentication
Reference from msdn: https://msdn.microsoft.com/en-us/library/ff647503.aspx
I'm new to WCF and I have a relatively simple question that I can't seem to find a simple answer for. I am trying to see if I have to explicitly use certificates to verify both ends of the binding are genuine. I would prefer to use the TcpClientCredentialType.Windows security to do it all for me with ProtectionLevel.EncryptAndSign. Is this sufficient for both client and server to trust each other that they haven't been tampered with? Both my client dll and the server processes are signed with the same certificate but could somebody just create a fake service that uses my contract and my client would not realise?
MSDN contains a list of the best practices to consider when creating secure applications using Windows Communication Foundation (WCF).
WCF offers two mechanisms for peer-to-peer authentication: X509 certificates (used by peer channel) and Windows authentication where an SSPI negotiation downgrades from Kerberos to NTLM. Certificate-based authentication using key sizes of 1024 bits or more is preferred to NTLM for several reasons:
the availability of mutual authentication,
the use of stronger cryptographic algorithms, and
the greater difficulty of utilizing forwarded X509 credentials.
For what it's worth, you may want to consider certificates, even self-signed certificates, to ensure optimum endpoint security.
There's a load of stuff to cover, so I'll try to keep it structured, as all good programmers should.. bear with me.
My Environment
.NET 3.5 SP1 Smart Client
Uses WCF+SOAP over HTTP to communicate to server for business logic / data access
Typically uses a custom (username+password) or Windows authentication scheme
Current work aims to extend to include a new Claims-based authentication scheme to facilitate SSO with ADFS
So far...
Main service endpoints using ws2007FederationHttpBinding bindings, configuration set up with Message security via trust/13/issuedtokenmixedsymmetricbasic256 ADFS 2.0 endpoint
Issuer endpoint configured with IssuedTokenOverTransport to HTTPS trust/13/usernamemixed ADFS 2.0 endpoint
Service has federateServiceHostConfiguration service behaviour specified
Created temporary certificate authority (CA) cert
Created temporary certificate signed by CA
Installed certificate (including private key) and made available to IIS app pool process account
Updated service WCF config to use X509 certificate
Client modified with new app’s own Client scheme/mode, programmatically sets up channel factory to ignore errors caused by temporary certificate and disables certificate revocation checks
Username/password credentials are successfully added (via standard WCF ClientCredentials object) to SOAP envelope of token requests
Token is successfully generated by usernamemixed endpoint and is returned to the client
My problem
Immediately following the token being issued, the subsequent call to issuedtokenmixedsymmetricbasic256 endpoint fails with generic error message that the security of the message could not be validated. Inspection of the SOAP envelope result gives no information at all beyond a simple ‘failed’ result enumeration value
Full tracing has been enabled on ADFS 2.0 server, but no events are logged at all in Event Log or event traces to further diagnose
Unable to configure to work in a federated manner thus far; token is successfully issues over usernamemixed endpoint in the ‘test’ environment (the internal ADFS server rather than a remote one). Use of the ‘live’ environment gives a simple unexplained 401 HTTP status code whether using usernamemixed with confirmed and valid credentials, or windowsmixed, when trying to obtain a token
Generally: Resources from Microsoft or other sources are either very scarce, very specific to one situation, and in a couple of cases, completely wrong or misleading
So ask a question already, doofus
Why does the call the issuedtokenmixedsymmetricbasic256 that WCF makes after getting the token fail? How can I diagnose the result? Other than what I've already done - enabling all trace flags in the service host config, checking the event log and event tracing data, what can I do?
Note, if you're about to suggest a link to a screencast/guide/blog/seemingly all-encompassing MSDN article, please stop. I believe I have found them all, tried them all, and what I need at this point - if you can help me please - is an answer to the above question. Not a general resource.
I am building a wcf service that needs to be secured as information that the client inter-exchanges with the service is sensitive to the company. I am planning to have it hosted on iis6. What would be the best practice to make sure that nobody but the client application can call the service to get/set data?
The service calls need to happen under the user's real identity as all the calls have to be monitored and audited. I am planning to use PolicyInjection for audit calls.
It all depends.
But basically there are two main approaches:
Transport security with SSL with basicHttpBinding
SSL security with wsHttpBinding
If you provide more information, I should be able to help you more.
There are certain aspects of security:
1) Data integrity: no-one has tampered with data but the data itself are not secret. This is achieved by signing.
2) Data security: This is so that no one could see sensitive/secret information. This is by encryption.
3) Authentication: this is by sending username/password or using certificates. This makes sure the person is the same who is claiming.
4) Authorization: This is to make sure the person has access to the specific features in the service.