views:

22

answers:

2

It seems like I'm barking up the wrong tree when asking this question, this question and this question.

I need to authenticate users against a custom API (in COM), and I need to keep that custom API (the COM object) alive (for that user) for future WCF calls. During authentication against that custom API, I can get back a list of custom-defined roles. I'd also like to use these for authorization of the service methods.

Moreover, I need to be able to revoke the user's session remotely. This is triggered by an event raised by the COM API.

I've got a custom UserNamePasswordValidator, but it appears that this has no mechanism for correctly setting a custom principal, so it looks like I'm heading in the wrong direction.

How do I do these three things?

A: 

You can handle authentication completely in your service. Create service contract similar to:

[ServiceContract(SessionMode=SessionMode.Required)]
public interface IService
{
  // All your operations marked with [OperationContract(IsInitiating=false, IsTerminating=false)] 

  // Two additional operations
  [OperationContract(IsInitiating=true, IsTerminating=false)] 
  void Login(string user, string password);

  [OperationContract(IsInitiating=false, IsTerminating=true)] 
  void Logout();
}

Service implementing this contract has to have PerSession instancing. Implement authentication in Login method and store COM object in local field. When new client want to use such service he has to first call the Login method. So all your instances will be properly authenticated and they will store their instance of COM object.

You can also register InstanceContext and COM object to some global class which will deal with forcibly killing service instance. This will probably require some research to make it work.

Make sure that you use some secure binding (encryption) because you will send user name and password as a plain text.

Ladislav Mrnka
Useful, but is there any way to use this to do [PrincipalPermission]-based stuff? Or do I have to do it imperatively?
Roger Lipscombe
This solution doesn't use role base security. If you want to use declarative role based security you have to dive deep into WCF internals - than we are going back to custom authorization policy.
Ladislav Mrnka
A: 

Doing this with custom authorization policy is covered here.

Roger Lipscombe