I'm fairly new to WCF development and have run into a couple problems whilst learning the framework. I have a service api which must support both REST & SOAP. So far this has been easy to implement especially with WCF4 and routing.
I am currently working on authorization and have managed to extend AuthorizationManager by creating two new manager classes: "ApiKeyAuthorizationManager" & "ApiKeyAndTokenAuthorizationManager"
Most of my services will require an ApiKey and Token (GUIDS) to be present; when initially authenticating, you simply need a valid ApiKey and password to receive a Token.
So far REST is working perfectly as the Authorization managers look to the query string to get ApiKey and/or Token.
So for example a service uri would look like: *http://api.domain.com/Service/Operation/{someVariableValue}?ApiKey=GUID&Token=GUID
My problem now comes with authorizing SOAP service calls. I've done a little bit of research and have come to a few conclusions I wanted to verify are correct before implementing.
In order to authorize SOAP with custom credentials I should:
Am I on the right track for this? Are all these steps needed to fit my scenario? Seems like so much customization for just verifying a credential made up of two GUIDs.
Thanks!
[EDIT #1]
This has been a very difficult task. Custom credentials and security tokens is nearly undocumented. Finding quality blog posts itself has proven near impossible. I've kept plugging away and am so close to have a working solution. I've even hit the same road blocks as described in this post.
When I try to access my service to uncover the wsdl or mex I receive this error:
The service encountered an error. An ExceptionDetail, likely created by IncludeExceptionDetailInFaults=true, whose value is: System.InvalidOperationException: An exception was thrown in a call to a policy export extension. Extension: System.ServiceModel.Channels.SymmetricSecurityBindingElement Error: Specified argument was out of the range of valid values. Parameter name: parameters ----> System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values. Parameter name: parameters at System.ServiceModel.Security.WSSecurityPolicy.CreateTokenAssertion(MetadataExporter exporter, SecurityTokenParameters parameters, Boolean isOptional) at System.ServiceModel.Security.WSSecurityPolicy.CreateWsspSignedSupportingTokensAssertion(MetadataExporter exporter, Collection`1 signed, Collection`1 signedEncrypted, Collection`1 optionalSigned, Collection`1 optionalSignedEncrypted) at System.ServiceModel.Security.WSSecurityPolicy.CreateWsspSupportingTokensAssertion(MetadataExporter exporter, Collection`1 signed, Collection`1 signedEncrypted, Collection`1 endorsing, Collection`1 signedEndorsing, Collection`1 optionalSigned, Collection`1 optionalSignedEncrypted, Collection`1 optionalEndorsing, Collection`1 optionalSignedEndorsing, AddressingVersion addressingVersion) at System.ServiceModel.Security.WSSecurityPolicy.CreateWsspSupportingTokensAssertion(MetadataExporter exporter, Collection`1 signed, Collection`1 signedEncrypted, Collection`1 endorsing, Collection`1 signedEndorsing, Collection`1 optionalSigned, Collection`1 optionalSignedEncrypted, Collection`1 optionalEndorsing, Collection`1 optionalSignedEndorsing) at System.ServiceModel.Channels.SecurityBindingElement.ExportSymmetricSecurityBindingElement(SymmetricSecurityBindingElement binding, MetadataExporter exporter, PolicyConversionContext policyContext) at System.ServiceModel.Channels.SecurityBindingElement.ExportPolicy(MetadataExporter exporter, PolicyConversionContext context) at System.ServiceModel.Description.MetadataExporter.ExportPolicy(ServiceEndpoint endpoint) --- End of inner ExceptionDetail stack trace --- at System.ServiceModel.Description.ServiceMetadataBehavior.MetadataExtensionInitializer.GenerateMetadata() at System.ServiceModel.Description.ServiceMetadataExtension.EnsureInitialized() at System.ServiceModel.Description.ServiceMetadataExtension.HttpGetImpl.InitializationData.InitializeFrom(ServiceMetadataExtension extension) at System.ServiceModel.Description.ServiceMetadataExtension.HttpGetImpl.GetInitData() at System.ServiceModel.Description.ServiceMetadataExtension.HttpGetImpl.TryHandleDocumentationRequest(Message httpGetRequest, String[] queries, Message& replyMessage) at System.ServiceModel.Description.ServiceMetadataExtension.HttpGetImpl.ProcessHttpRequest(Message httpGetRequest) at SyncInvokeGet(Object , Object[] , Object[] ) at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs) at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc) at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc) at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31(MessageRpc& rpc) at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)
If you have any idea what might be causing this I'd love some help.
[EDIT #2]
It seems Microsoft doesn't want to update their samples to show how to allow wsdl support for custom credentials / tokens. See here. Anyone have an idea how to get this working? What's the point of making a framework extensible if there's no documentation how to extend it?!?
[EDIT #3]
As stated in my comment below... I have TransportWithMessageCredential working just fine using UserNameSecurityToken. Unfortunately, my services will end up requiring custom tokens when it's time to implement some more advanced features that I have planned.
What I'm looking for as an answer would be:
How to support custom service credentials and tokens with WSDL support?
Currently, following Microsoft's examples, you can only use custom credentials by using ChannelFactory and creating a custom binding on the client. I would rather not deal with that.
If this question remains unanswered, I'll keep upping the bounty. As soon as I can get this all working I'll write up a blog tutorial on all the steps required to creating a custom security solution.
I would advise you look to Windows Identity Foundation, and move in the direction of claim based security/federation. This model supports custom credentials much better as they are just a different set of claims.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With