My first question would be: what are you accessing the service for? Create users? delete users? change claims to be issued? Get more information about a specific user?
Are these operations going to be executed by all users (like in "self service" use cases)? only by some (e.g. admins)?
You could use claims to protect this service. In that case, if the ASP.NET app calls the membership/related data service on behalf the original user, then you would need to get an "ActAs" token (from the same STS).
You could also opt for a "trusted subsystem" approach where the site calls the service with its own identity. In that case you can use claims (no "ActAs" necessary) or some other authentication (like an API key).
It also depends on how the service is implemented (as in REST, SOAP, etc). SOAP would require implementing WS-Trust (using WIF or WCF), REST would require using something else.