WCF: Using custom security

For various project / legacy reasons, none of the out-of-the-box
security options quite meets my scenario, so I wish to provide my own
security.

Does anybody have a link (or direct explanation) to the correct way to
do this? As a first-stab, I have implemented IEndpointBehavior
(config), IDispatchMessageInspector (server), IErrorHandler (server)
and IClientMessageInspector (client), so that my client adds a SOAP
header, which is parsed at the server and used to set the
Thread.CurrrentPrincipal - however, I suspect I am missing a few
tricks, such as the entire IndentityModel area - but I simply couldn't
seem to find the route into this... is there one? My current approach
works, and allows role-based security to work within the main method
call, but it is trashed before IErrorHandler kicks in (to log the
offending user along with messages), forcing me to re-parse the header
(using OperationContext.Current in ProvideFault; the headers are gone
by the time HandleError is called)

Also - maybe I am just not spotting the property, but how can you get
the calling node's details (IP and whatever else is available) from
WCF? There are a range of likely-looking properties, but at runtime
they all seem to be null... again, this is for error-logging,
especially for logging intrusion attempts when verifying the integrity
of the security header.

Marc

Marc,

Here are some things to get you started on creating your own custom WCF
security model:

You are going to need to create your own Identity and Principal objects to
handle the data you want within context. Inheriting from
System.Security.Principal.IIdentity and System.Security.Principal.IPrincipal
is a good idea.

Also, to validate usernames and passwords you'll need to create your own
custom username and password validator by inheriting from
System.IdentityModel.Selectors.UserNamePasswordValidator.

Then, you'll need to create your own AuthorizationManagers and
AuthorizationPolicies by
inheriting from System.ServiceModel.ServiceAuthorizationManager and then
overriding the CheckAccessCore(OperationContext operationContext) method to
perform additional checks for your model.

Also, you'll need to create your own AuthorizationPolicy by inheriting from
System.IdentityModel.Policy.IAuthorizationPolicy. Within this interface
you'll have to evaluate the caller's context and give out the appropriate
permissions.

When all of that is done, you'll need to modify your service configuration
to use these custom assemblies in the following configuration tags:

<serviceBehaviors>
<behavior name="MembershipServiceBehaviors">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
<serviceCredentials>
<userNameAuthentication userNamePasswordValidationMode="Custom"
customUserNamePasswordValidatorType="MYCUSTOMVALIDATORTYPE",
CuraScript.MembershipServices.Validators" cacheLogonTokens="true" />
<windowsAuthentication allowAnonymousLogons="false" />
</serviceCredentials>
<serviceAuthorization impersonateCallerForAllOperations="false"
principalPermissionMode="Custom"
serviceAuthorizationManagerType="MYCUSTOMAUTHORIZATIONMANAGER,
MYCUSTOMAUTHORIZATIONMANAGERASSEMBLY">
<authorizationPolicies>
<add policyType="MYCUSTOMAUTHORIZATIONPOLICY,
MYCUSTOMAUTHORIZATIONPOLICYASSEMBLY, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=null" />
</authorizationPolicies>
</serviceAuthorization>
</behavior>
</serviceBehaviors>

I hope this helps. Let me know if you have anymore questions.

Shaun McDonnell

"Marc Gravell" <marc.gravell@gmail.com> wrote in message
news:eGkZElPSHHA.1364@TK2MSFTNGP06.phx.gbl...
> For various project / legacy reasons, none of the out-of-the-box security
> options quite meets my scenario, so I wish to provide my own security.
>
> Does anybody have a link (or direct explanation) to the correct way to do
> this? As a first-stab, I have implemented IEndpointBehavior (config),
> IDispatchMessageInspector (server), IErrorHandler (server) and
> IClientMessageInspector (client), so that my client adds a SOAP header,
> which is parsed at the server and used to set the
> Thread.CurrrentPrincipal - however, I suspect I am missing a few tricks,
> such as the entire IndentityModel area - but I simply couldn't seem to
> find the route into this... is there one? My current approach works, and
> allows role-based security to work within the main method call, but it is
> trashed before IErrorHandler kicks in (to log the offending user along
> with messages), forcing me to re-parse the header (using
> OperationContext.Current in ProvideFault; the headers are gone by the time
> HandleError is called)
>
> Also - maybe I am just not spotting the property, but how can you get the
> calling node's details (IP and whatever else is available) from WCF? There
> are a range of likely-looking properties, but at runtime they all seem to
> be null... again, this is for error-logging, especially for logging
> intrusion attempts when verifying the integrity of the security header.
>
> Marc
>

Thankyou for this detailed reply. I will try to work my way through it
;-p

My identity is based on a ticket rather than a password; in fact, in
some ways it could be considered federated, but I'll start looking at
this and see where I get...

Marc

It has been a while, but I have finally gotten around to this (project
priorities shifted), and I just wanted to let you know that it all
went well, and is now fully working. Thanks again for the reply - it
is very much appreciated.

Regards,

Marc