"Обычный" WebService наследует от System.Web.Services.WebService и соответствующий proxy наследует от System.Web.Services.Protocols.SoapHttpClientProtocol. WSE-enabled WebServices по-прежнему наследуют от System.Web.Services.WebService, но client получает 2 proxy : "обычный", наследованный от SoapHttpClientProtocol и новый, наследованный от Misrosoft.Web.Services.WebServicesClientProtocol.
По умолчанию, WSE proxy будет называться с приставкой Wse, как например, если WebService называется Service1, то WSE proxy будет называться Service1Wse.
WSE 2.0 поддеживает несколько типов digital signing of WS-Security. Рассмотрим самый простой из них : digital signing with UsernameToken Security Token. The process works as follows:
1). A-priori both client and server establish shared secret information, such as unername-passoword credentials. They take their own responsibility to store these credentials in a secure location. The passwords never transmitted accross the wire.
2). The client generates UsernameToken security token:
public
static UsernameToken CreateToken(string strUserName, string strPassword){
string username = strUserName; //Environment.UserName;
byte[] passwordBytes = System.Text.Encoding.UTF8.GetBytes( username );
Array.Reverse( passwordBytes );
string passwordEquivalent = Convert.ToBase64String( passwordBytes );
UsernameToken token =
new UsernameToken( username, passwordEquivalent, PasswordOption.SendNone );
return token;
}
3). The client creates a digital signature based on the UsernameToken and adds it to the outgoing SOAP message:
Service1Wse serv =
new Service1Wse();serv.RequestSoapContext.Security.Tokens.Add(token);
serv.RequestSoapContext.Security.Elements.Add(
new MessageSignature( token ) );
4). The service receives the message and checks the security token type. Процесс определения, в какой SecurityManger направить запрос, происходит в самом WSE по типу SecurityToken. Например, типу Microsoft.Web.Services2.Security.Tokens.UsernameToken соответствует QName wsse:UsernameToken, как видно из след. рисунка:
[показать]Sic! SecurityMangers загружаются с помощью CAS, и фактически должны иметь
[SecurityPermissionAttribute(SecurityAction.Demand, Flags=SecurityPermissionFlag.UnmanagedCode)]
5). Once the service determines that a UsernameToken was used, it uses a token manager to extract the username and the password information that was used to sign the message. В реальной жизни никакие пароли, конечно, никуда не передаются - client посылает hash или все равно что, котрое можно вычислить на основе Username. Для этой проверки существует virtual метод UsernameTokenManger.AuthenticateToken() - он должен вернуть string, который WSE сравнит с переданым паролем или что-там-было вместо-него. If the creadentials do not match, then a SOAP exception is raised.
Отсюда простейший способ разрешить вызывать только зарегерстрированым пользователям :
protected
override string AuthenticateToken( UsernameToken token ){
string strUsername = token.Username;
if( strUsername.CompareTo("olegk") != 0 )
return String.Empty;
// Code here
}
Суммируя, опишем процесс WS-Security using UsernameToken другими словами: client "подписывает" свои сообщения с помощью digital signature. Этот digital signature формируется из token, созданного на основе username и password (шаг 3). Server, во-первых, распознаёт, что в переданном сообщении есть digital signature и что она создана на основе UsernameToken (автоматический процесс, выполняемый WSE). После этого Server находит cutom token manager, зарегестрированный в его web.config для этого типа tokens (см. шаг 4) и вызывает его, передавая полученный token. Из token всегда можно получить username, а дальше Server должен по нему восстановить password для того, чтобы воспроизвести digital signature. Для этого Server переопределяет функцию UsernameTokenManager.AuthenticateToken() - он должен вернуть из неё password. Возвращенный из этой функции password, используется дальше в token manager for reproduce digital signature.