*Words of Wisdom From The Elder

Hi,

First of all, thanks for the great article. It proved to be a big help! I love your solution but would like to make a modification to it. The problem is I’m not sure how to accomplish my goal.

I would like to return a 403 status code when the username /password is invalid. But how would I do this from the validate method and without the executing the webmethod that was called?

Just partly answering my own question here…

I have adapted the ServiceAuthHeaderValidation.Validate(ServiceAuthHeader) method to return an instance of my object rather than a bool. This means I’ve now got the thing I want sitting in an instance of AuthenticatonSoapExtension.

The thing I don’t know is how I can get access to that object from within my WebMethod. Could I find the instance of AuthenticatonSoapExtension that was just created? Maybe I should store my object somewhere else that can be read by the WebMethod.

I imagine there’s a Session or somewhere I could put it, but I’d like to go with best practices for WebServices and this isn’t my area of expertise, to be honest.

Thanks again for a really helpful couple of articles on this.

@Arun

What you are describing has already been solved and there is a standard around it. With ASMX services it isn’t that fun to implement. WCF is a much better option.

http://en.wikipedia.org/wiki/WS-Security

-Keith

Todd,

Bottom line is yes, you should only have SOAP enabled on your service for this to work. If you absolutely have to enable POST for some unknown weird reason then you’ll have to make that apart of your message. Something like:

public class CreditRequest
{
string token;
string FirstName;
string Email;
string SSN;

string ETc….;
}

CreditResponse credit = proxy.PullCredit(myCreditRequest);

Remember that POST is POX (plain old XML), therefore they have to pass it in as part of the regular message.

do need add any sp elements in wsdl

@Ghanshyam

Clarification real quick. You can attach credentials from the client side by adding them to the SoapHeader object in the client. The web service processes the soap header via the SoapExtension.

I wanted to clarify your first question because it didn’t make any sense to me the way it was worded.

In the client you would have code like this for your service:

MyService proxy = new MyService();
MyService.AuthHeader header = new MyService.AuthHeader();
header.Username = “foo”;
header.Password = “bar”;
proxy.AuthHeader = header;

proxy.CallSomeMethod();

This is what I mean by in the client you attach the credentials from the client side.

Hope that helps.

-Keith

Hi, Is it possible to send in the credentials from the clientside by attaching them to the WebService call by SoapExtension? I have tried inserting header dynamically in BeforeSerialize stage in ProcessMessage, but the header shows up as SoapUnknownHeader on the WebService side in the AfterDeserialize stage of ProcessMessage. What I mean is that caller’s of the webservices need not attach the authheader value everytime themselves, rather the SoapExtension do it. Another thing, is it possible to send in also some other dynamic data like which is dependent on the current session using SoapExtension class. I could not find anything apart from using CurrentPrincipal. Please advise.

If you really wanted to pass some type of access level for the method into the attribute, you could do something like this:

[MySecuritySoapExtension(AccessLevel=MyAccessLevel.Administrator)]

By doing something like this in your SoapExtension class:

private MyAccessLevel mAccessLevel = MyAccessLevel.User;

public override object GetInitializer(Type serviceType)
{
return mAccessLevel;
}

public override object GetInitializer(LogicalMethodInfo methodInfo, SoapExtensionAttribute attribute)
{
return (MyAccessLevel)((AuthenticatonSoapExtensionAttribute)attribute).AccessLevel;
}

public override void Initialize(object initializer)
{
mAccessLevel = (MyAccessLevel)initializer;
}

And in your SoapExtensionAttribute class add a public property like so:
private MyAccessLevel mAccessLevel = MyAccessLevel.RegisteredUser;

public MyAccessLevel AccessLevel
{
get { return mAccessLevel; }
set { mAccessLevel = value; }
}

MyAccessLevel being an enum with all the levels you desire:
public enum MyAccessLevel
{
Administrator,
User
}

Then in your ProcessMessage you could pass in the access level as a parameter to do your validation during Authentication or whatever you like.

SOAP extension is never going to fire.

I decided to deploy it on real server for test SOAP extension. Running the client from my computer and it still pass the authentication with wrong password.

Please help me!

Sure, it isn’t that bad really just takes a bit of wiring up. For starters look at the last sample above starting at line 48. This method takes the SoapMessage as a parmeter.

From the SoapMessage you have a property called SoapMessage.MessageName. Instead of attributing the methods as you did like this:

[PermissionsAttribute(“admin”)]
void SetValue(int value);

I would simply use this property to determine the Method the user is requesting, and then do a lookup in the database to map their permissions. I’ll try to write up an example on how I would do this and get it posted, it is a good follow up article. Stay tuned!

You’ve been kicked (a good thing) – Trackback from SecurityKicks.com