Are WCF sessions secure?

I am developing a WCF service with some kind of authentication.

All users will be equal, so I am planning to require sessions and have only 开发者_StackOverflow中文版a method that initiates a session and doesn't terminates it. Simplifying:

[OperationContract(IsInitiating = true, IsTerminating = false)]
void Open(String user, String password);

So, if the password is wrong (again, this is a simplification) I would raise an exception so the session would end. This way, I don't need to check credentials in every method call.

Is this a good approach? If not, why?

Update: I had to write this on a hurry so I'll try to elaborate a bit and make my question clearer.

The authentication method is a requirement, and I'm not asking about it. I want to know about session managing.

When I use the [OperationContract(IsInitiating=true, IsTerminating=false)] a session is started. I don't need to store an ID or anything; WCF manages everything. When an exception is raised or a method with IsTerminating=true is called, the session ends, and subsequent calls to the service methods fail, until a new session is initiated.

What I want to know is if it's reasonably easy for an attacker to bypass the WCF session management stuff, creating one on its own without calling Open, the only method of my service with IsInitiating=true and IsTerminating=false, so, the only way to lawfully start a session.

WCF sessions can be as secure as you like, depending on the binding you choose.

http://msdn.microsoft.com/en-us/library/ms731172.aspx

However, I would suggest that the above would not work, because your method returns no value to the calling client to indicate what it should pass in subsequent calls (i.e. a session ID) to authenticate itself.

A better approach might be to do all your security checking in the bindings (see link above for the vast array of options), leaving the service itself to just expose methods and not worry about authenticating clients.

Yes, it would be trivial for a malicious client to "hijack" an authenticated session unless you encrypt all comms that carry the session identifier using an encryption key that is not accessible to potential comms interceptors. Then again, it would be equally simple for them to intercept the transmitted user names and passwords too without adequate encryption and anti-replay protections.

Sometimes requirements need to be revisited once implementation choices start being made. It sounds like this might be one of those cases...