Onvif支持两种鉴权方式，一种是WS-Security UsernameToken（常用，需要理解并实现），另外是Digest（RTSP取流也会用到的鉴权方式，如果只是做客户端的方向的话，可以尝试了解）。
绝大部分的数据请求都是需要用户权限的，所以鉴权是非常重要的基础部分内容。
一般基础的鉴权信息都是用户名加密码，Onvif是支持明文直接传输，但是不太建议使用，且目前市面上的IPC也不太支持明文传输。
一、WS-Security UsernameToken
<Envelope>
<Header>
<Security>
<UsernameToken>
<Username>root</Username>
<Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">EVpXS/7yc/vDo+ZyIg+cc0fWdMA=</Password>
<Nonce>tKUH8ab3Rokm4t6IAlgcdg9yaEw=</Nonce>
<Created>2010-08-10T10:52:42Z</Created>
</UsernameToken>
</Security>
</Header>
<Body> </Body>
</Envelope>
上面是一个简单的例子，可以看在Header里面UsernameToken节点。里面含有4个关键的信息
1、Username：用户名信息。
2、Password：加密后的密码数据，用来给服务端校验。
3、Nonce：一个随机的数据，base64编码。
4、Created：日前信息，用来加密Password数据。
公式如下：
Password = Base64Encode(SHA1(Base64Decode(Nonce) + Created + password))
如上面的例子中：Username为root，假设真实密码为123456，代入上面的公式就是
"EVpXS/7yc/vDo+ZyIg+cc0fWdMA=" = Base64Encode(SHA1(Base64Decode("tKUH8ab3Rokm4t6IAlgcdg9yaEw=") + "2010-08-10T10:52:42Z " + "123456"))
关于Nonce的生成规则只要保证随机性即可，最好能保证每次的Nonce为唯一，可以以当前的毫秒数+随机数为Nonce的源数据进行base64编码。因为有的厂家会对Nonce进行次数的有效性验证，即相同的Nonce的验证次数有限，在多并发的场景下，很容易会忽略导致验证失败。
二、Digest摘要认证
暂时不介绍，资料可以参考百度其他协议。
