CODEWITHSUNDEEP
asp.netwcfsessioncachingauthentication
andrew
andrew

Reputation: 1030

asp.net, wcf authentication and caching

I need to place my app business logic into a WCF service. The service shouldn't be dependent on ASP.NET and there is a lot of data regarding the authenticated user which is frequently used in the business logic hence it's supposed to be cached (probably using a distributed cache). As for authentication - I'm going to use two level authentication:

  1. Front-End - forms authentication back-end
  2. (WCF Service) - message username authentication.

For both authentications the same custom membership provider is supposed to be used. To cache the authenticated user data, I'm going to implement two service methods:

1) Authenticate - will retrieve the needed data and place it into the cache(where username will be used as a key)
2) SignOut - will remove the data from the cache

Question 1. Is correct to perform authentication that way (in two places) ?

Question 2. Is this caching strategy worth using or should I look at using aspnet compatible service and asp.net session ?

Maybe, these questions are too general. But, anyway I'd like to get any suggestions or recommendations.

Any Idea

Upvotes: 2

Views: 777

Answers (4)

Vano Maisuradze
Vano Maisuradze

Reputation: 5899

My suggestion is to create class Authentication (or something else) on WCF side:

public class Authentication<T>
{
    public static Dictionary<string, T> Users { get; set; }
}

And if you have User class:

public class User
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    ...
}

You can manage users like this:

Authentication<User>.Users.Add("username", new User());

Upvotes: 0

rosencreuz
rosencreuz

Reputation: 1297

Passing the password to between the services is not a good practice. You should consider creating a custom security token in your front-end application and passing this token to the WCF service. WCF service can validate the token using a certificate. With this approach you can

  • insert any user data into the security token and use in the WCF service
  • cache the token in the front-end application session, therefore you don't need any distributed cache
  • centralize login and avoid authenticating user twice

Upvotes: 1

Fabske
Fabske

Reputation: 2126

If you don't want to be dependant on ASP.NET then you shouldn't use any session

What I could advice:

  1. Use a UserNameValidator, so that you need to send username/password on each request to the wcf service (there are a lot of article on the web on how to configure a UserNameValidator)

  2. Implement an IAuthorizationPolicy where you can retrieve user data to set the roles etc. This object is created once then reused

The problem is that if you only use these 2 components, you'll need to fetch the data for each request as you've no way to transfert the username from the UserNameValidator to the IAuthorizationPolicy To avoid that, you'll need to implement the complete authentication mechanism in WCF. It's not hard at all, and here is a very nice link that help me to do it in 1 or 2 hours:

http://www.neovolve.com/post/2008/04/07/wcf-security-getting-the-password-of-the-user.aspx

The "PasswordAuthorizationPolicy" (in the link above) is created once, then reused. And for each request the Evaluate method is called.

It means that you can add any custom property on this class, fill them in the constructor, and then use them forever. You don't need to manage this cache lifetime as it's binded to the client channel, so once the client close the connection the channel will expire all these data will be removed from memory

Upvotes: 0

wachpwnski
wachpwnski

Reputation: 688

Question 1:

From my experience the ASP forms authentication would be enough. No reason to send credentials as POST and certainly not GET. You can use that for a change password or account info method. You might want to look into Membership and Roles.

Question 2:

I would stick with the ASP.NET session. This might make your application more prone to issues and vulnerabilities in the end, and I see it as unnecessary.

Upvotes: 2

Related Questions