Custom Authentication/passing additional into with WCF/SF

Topics: General Discussion Forum, July and December Releases Forum, Service Factory Modeling Edition Forum
Mar 24, 2008 at 5:32 PM
Following is our requirement and I am wondering if someone can suggest recommended approach or any pointers around this:

- Intranet only solution -hosted on IIS -hosted on client's enviroment as we sell this as product to multiple clients.
- .NTE 3.0, WCF, WSSF

- Need to pass user/pwd details from client to esrvice
- We need to retrieve both user name and password on server-side and use it for custom authenticatoin and for database connections
- We can not use certificate options As it will force all our clients to manage certificates and as of now and we don't want to go with test certificates
- We are looking for ASP.NET/Forms based custom authentication style Looking for similar option in WCF terms
- We want to pass user/pwd details only once and each service call can somehow figure out if authentication is done and should be able to get both User/PWD details
- Each service call will then need to use this specific Usr/Pwd to re-use some legacy product functionality and for database connections

What we are doing now:
- We pass user/pwd details in message header for each service. So this way service methods don't have user/pwd parameters.
- But this requires us to pass user/pwd detials everytime and worry about encryption etc.

What we want to do:
- Create authenticate metho that takes user/pwd
- Use messgae level production on WCF for this method only
- On server side, somehow remember this user/pwd detials in some context This is where I am not clear what is recommended context that can do this
- We want to avoid using any ASP.NET session and depend more on WCF properties/context as much as possible
- Solution should work in web farm sceanario

I would appreciate any pointers on this. Please take above details into consideration for your suggestions so that your response is more useful for us

Thanks for your time.

Apr 1, 2008 at 4:32 PM
... Following is what I come up with. It helps me if someone with good experience around WCF security, can comment on the approach:

Solution I am looking is very well documented with sample code:

Main change I did to avoid our requirement of not dealing with certificates from all client machines is:
- Change Client configuration attribute as follows:
<authentication certificateValidationMode="None" />

So far my testing works on same machine and different machines. We don't need to go with HTTPS etc OR letting clients get to certificate store etc.

In this option also, I need to install certificate on server machine (For now some test certificate in DEV) but we don't need client to look for certificate store etc with No validation option.

Following are my questions:
- What are the risks in this case One, I can think of is - we can not authenticate server machine. But we run in controlled env
- Do you know if messages are still encrypted and we have extra encryption load on message?

Since we can always change these things at config file based on client's deployment environment, we can always go to full secure mode if required.

I was looking at "TransportWithMessageCredential" option -it seems like better than "Message" mode security - as we don't have message encryption penality - Is that correct assumption. Documentation is not clear -why it is best of both options "Transport' and "Security". In this case we still end up using HTTPS, so I did not go for this. More details help.

Thanks for your time
Apr 1, 2008 at 6:12 PM

The suggested solution in that link is fine, but you may know the implications of you suggested change. First of all, you are using only one certificate (server side) that will be used for authentication and sign/encrypt the credentials (username/pwd) sent to the server.
Now when you set "None" the the certificateValidationMode attribute you are basically turning off the server authentication which basically means that your client won't verify the identity of the server. Assuming you are on a "closed" environment this may be a "reasonable" risk. Now regarding the message security, I suggest to NOT turn off this since even in a controlled environment that may poses a high risk of disclosing sensible data like credentials. Notice that TransportWithMessageCredential will encrypt the channel with SSL so you will also have the "penalty" of encryption but regarding comparative performance between each setting, you should get your own testing in order to check which one better fits your needs.