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.
Related
I'm working on securing some Azure Functions endpoints. I tried with Certificate, but I hit a few walls
In the FunctionsStartup (from which derives my startup) I could not find a way to connect my AddAuth and Auth methods/classes. (I tried to search, read more on this topic, but all the answers were either for web API other type of Authentications)
I tried to check for the existence of a certificate at least, but that didn't worked either. I tried to get the certificate from request-context-connection-ClientCertificate or to read it from headers. Didn't worked locally or on deployed version. The certificates are always null.
I saw that there are some options to secure it with AD(also with facebook, google and so on), but first I'm curious if someone successfully implemented another Auth method, more like in a classic web api approach (JWT tokens, certificate, other similar stuff)
Access restrictions enable you to define a priority ordered allow/deny list that controls network access to your app. The list can include IP addresses or Azure Virtual Network subnets. When there are one or more entries, there is then an implicit "deny all" that exists at the end of the list.
Also you can request a client certificate when the client request is over TLS/SSL and validate the certificate. This mechanism is called TLS mutual authentication or client certificate authentication.
First, your App Service plan must be in the Basic, Standard, Premium, or Isolated tier.
Secondly, enable client certificates:
az webapp update --set clientCertEnabled=true --name <app_name> --resource-group <group_name>
Finally, Access client certificate. App Service injects an X-ARR-ClientCert request header with the client certificate. Your app code is responsible for validating the client certificate.
For more details about how to configure TLS mutual authentication for Azure App Service, please refer to this article.
This question is not about HOW something can be done. Everything is working fine. I like to know, if it is "ok" to do the authentication / authorization process inside a WCF message inspector.
Currently I am working on a client/server application with a WPF client and a self-hosted WCF server. The used protocol is Net.Tcp and all SOAP messages are AES256 message-encrypted and signed. Also all send SOAP message-headers are always message-encrypted and signed.
The complete auth process looks like this:
Both server and client are always sending certificates to authenticate each other
Client receives a list of all endpoints it can connect to
Client sends User/Pass to authenticate and gets a session-id from the login-service
The session-id, the user-id and all user-rights associated with the user-id are stored into RAM in a singleton service, which is available system-wide inside the server application.
On every further request after the first login, the client only sends the session-id and a certificate inside a custom message-header, no more user/pass combination.
The situation:
Before a request from the client reaches any webservice operation, a message inspector reads the session-id and the requested webservice operation. It then uses the available singleton-service to determine if the session-id is still valid and if the associated user-id has the right to do this webservice operation. If not a fault-exception is thrown.
The question:
Is there anything wrong, to do the authentication / authorization process inside a WCF inspector?
If its working then dont break it :) But to answer you, I have put some insights for your to consider:
1- For service operations that dont require authentication, you would have to change the inspector code to whitelist them. This contradicts with the open close principle where your class must be open for extensions and closed for modification.
2- If later on, you decide to modify your authentication mechanism and use a third party component, you would have to modify your interceptor code drastically.
I usually use the WCF inspector to pass the token and other related info into my services classes where i normally implement the cross cutting concerns (Validation, Authentication, Authorization, Logging and exception handling). When you inject your authorization engine into your services, it becomes easier for you to first swap the mechanism when need be, second unit test your service method in isolation of whatever authentication mechanism you are using.
We have created a downloading client-service model application in which a WCF service is hosted on one of our servers and the client application is distributed among the partners.
Partners are provided with unique pin using which they can authenticate themselves with the WCF service and can place requests for downloading to the WCF Service.
The clients connect to the WCF Service through Windows Azure Service Bus within which we have created a namespace using which client applications can connect to the service.
Every namespace has a Default Issuer and Default Key. We have embedded this Default key in our code when connecting to the service bus.
Somebody told me that the key needs to be secured and you need to get the application signed in order to protect the embedded key. Is that true?
Do we really need to secure this key?
If yes then how? and Is there a way we can simply provide authentication in Service Bus which identifies the clients from their pins and and allows only a set of people to access the service bus namespace?
OR
I'm uselessly getting worried on such points? :)
We are using Service Bus Relay.
I have been reading about SAS and ACS and it seems according to the documentation that SAS is not supported for Relays. Following is the link:
"Support for Service Bus relays will be added in the near future."
http://msdn.microsoft.com/en-us/library/windowsazure/dn170477.aspx
I am unable to understand how to use ACS for authenticating clients. The information provided in the Windows Azure documentation are all bouncers for me and I can not relate them to anything no matter how hard I try.
If somebody has any information for my concerns then please help me with proper links and guidance.
Thanks!
EDIT!!!
I have been searching on this and the following link provides a methodology for creating an unauthenticated client:
http://msdn.microsoft.com/en-us/library/microsoft.servicebus.nettcprelaybinding.aspx
by using following tag in my client App.Config
<security relayClientAuthenticationType="None" />
I have tried this, but getting the below error:
"Generic: There was an authorization failure. Make sure you have specified the correct SharedSecret, SimpleWebToken, SharedAccessSignature, or Saml transport client credentials. MissingToken: Relay security token is required."
I'm looking more about this error. But few questions arise.
If we make the azure service bus accessible without authentication, can somebody simply misuse the service bus for their own advantage?
Do we really need to secure this key?
You store Issuer and Default Key on your server side.
To authorize on the Azure service bus, Service Bus WCF endpoint uses the Issuer and Default Key to create a token that will be signed with the Default Key that means that Default Key will never be sent to Azure.
Is there a way we can simply provide authentication in Service Bus
which identifies the clients from their pins and and allows only a set
of people to access the service bus namespace? OR I'm uselessly
getting worried on such points?
As far as I understood you have already implemented some kind of security on the WCF side.
There is another one way of doing that. You can use ACS to authentificate Clients. By Default Azure relay Service provides Support for the Simple Web Tokens.
Here is the workflow:
Client send UserName/Password( or UserName/Key) to the ACS.
ACS validates whether the credentials are valid.
ACS send the SWT token back to the Client.
Client packs the SWT token onto the HTTP request(for instance into
headers)
Client sends a request to the Web Service with the token in Header.
WCF web Service recieves the token and validates the token with the
secured shared key that was provided from ACS Namespace.(note that
this key is not sent during the communication it has to be manually
copied from the ACS Portal to the web Service config file)
If token is valid then web Service sends data to the Client.
I'm currently developing a web api, with WCF web api, which allows me to write restful apis. One concern I have is security. For this reason I decided to protect my api with the OAuth protocol which works very good. However, the team got to the conclusion that our own applications shouldn't be authorized by oauth, instead they sould be authorized by http basic, meaning that the client application should send username and password.
So I have 2 questions:
How can I set up WCF Web Api to work with SSL, I'm using Web Api preview 6, and the project is a MVC3 application?
I have an operation handler which takes care of the creation of IPrincipal from the client access token, and then injects it into the operation parameters, so I can access the user's info. I would like to have in the same operation handler a condition where I could check if the authorization scheme is OAuth or http basic, and then in the case of http basic extract the user's credentials and authenticate that specific user against my data base, if authentication is successful create an IPrincipal and inject it to the operation parameters. However, as I see it, everytime an application using http basic requests something to the api, I would have to go to the data base and authenticate. So my question is: Am I in the right path, or this could be accomplished in some other way?
Any answers would be appreciate it. Thank you in advanced!
You setup SSL for WCF Web API just like you would any other WCF service exposed over HTTPS. If you are hosted in IIS, then you need to configure a site binding for HTTPS. If you are self hosted, then the configuration is bit more involved. See http://msdn.microsoft.com/en-us/library/ms733768.aspx for all of the details.
To handle basic auth against a custom identity provider you would typically use a custom authz module when hosted in IIS. See [http://custombasicauth.codeplex.com/] for an example of how to do this. If you are self hosted then you can use a custom username passworld validator. See http://msdn.microsoft.com/en-us/library/aa702565.aspx for details.
Yes, I believe you are correct that every request will require authentication unless you establish some sort of session-like semantics.
Hope this helps.
I'd like to use client certificates to verify the identity of administrative callers to my web service. Then I can issue certificates only to the people I want to call my web service and be pretty sure noone else can call it. This is in a very controlled scenario where only one or two people will get the client certificate, so distribution isn't a hard problem.
This article provides a good example of how to call a web service using a client certificate.
But how can I check details of the client certificate from within my web service? This old article talks about configuring IIS to do it, but I'd like to do it programmatically within my app. I think?
thanks for any suggestions!
The incoming Request has a ClientCertificates collection that you can interrogate -- you can check the various fields in the cert or check the actual raw byte data (perhaps against a datastore or other source) if you want to completely validate it.
Note, if you issue the certs from your own private CA, you will need to install the CA's cert on your webserver into a store that is visible to all users, otherwise IIS won't request those certs from the user (due to the nature of how the server/client interaction works.)