The answer depends on whether you're using your WCF service like a web server (using REST, BasicHttpBinding, WSHttpBinding, or WebHttpbinding), or whether you're using a more network-like protocol like NetNamedPipeBinding. With a network-like protocol, you can establish live sessions that persist for as long as you want after the user has signed in.
However, assuming you're using one of the web-centric protocols, you can't really set up first, second, n-th layers of security. You can sent up a custom credential listener (like what Paramosh points to) that catches the user BEFORE he/she gets to the service, but that's it. There are no further events, so to speak, between the authentication event and when the request hits the fan.
So this is what I'd suggest: since http communication is nearly always a repeating set of requests and responses, have your authentication occur on first contact, giving the user (after they've submitted credentials) a SessionID (GUID) token that they can return with in as long as you want. The SessionID token would need to be stored on a DB somewhere, and on each subsequent visit the user would need to present that token for validation, but after that you've effectively got a live session scenario that should prevent unwanted intrusions. And this SessionID (or whatever you use) can be checked by the custom credentials function listed above.