我的博客列表

2014年2月9日星期日

iOS App 自定义 URL Scheme 设计


在 iOS 里,程序之间都是相互隔离,目前并没有一个有效的方式来做程序间通信,幸好 iOS 程序可以很方便的注册自己的 URL Scheme,这样就可以通过打开特定 URL 的方式来传递参数给另外一个程序。
例如在 iPad 上浏览网页,并且 iPad 已经安装了 淘宝 HD,那么就打开下面这个链接就会在淘宝 HD 中查看这个商品的详细信息,也可以方便的使用淘宝 HD 进行购买、收藏等操作。
当然,如果你在 Mac OS X 中打开这个链接,或者在没有安装 淘宝 HD 的 iPad 中打开这个链接,会提示没有程序来打开这个链接。

配置

要为 iOS 程序添加自定义协议的支持是一件很方便的事,只需要在程序的 Info.plist 添加一个 URL types 节点就可以了。在这个节点里,可以设置这个程序所支持的自定义协议名称,像 http、ftp 这种,一般我们可以设置为程序英文名称,像淘宝客户端中就设置了 taobao,这样 taobao:// 这个形式的 URL 就会关联到淘宝客户端的 App。
Info.plist config

实现

在 Info.plist 里面设置完 URL types 之后,就可以在程序中处理这类 URL 的打开请求了。
在外部程序中,如果打开了指定自定义协议的 URL,程序中 application delegate 的 application:handleOpenURL: 方法就会被调用,在这个方法里,可以获取到触发这个方法的 URL,可以通过对这个 URL 进行判断,例如根据不同的 Host,不同的 Query String 来执行不同的动作。
- (void)application:(UIApplication *)application handleOpenURL:(NSURL *)url {
    NSLog(@"%@", [url absoluteString]);

    // 在 host 等于 item.taobao.com 时,说明一个宝贝详情的 url,
    // 那么就使用本地的 TBItemDetailViewController 来显示
    if ([[url host] isEqualToString:@"item.taobao.com"]) {

        // 这里只是简单地假设 url 形式为 taobao://item.taobao.com/item.htm?id=12345678
        // 先获取要查看的宝贝详情的 itemId
        NSString *itemId = [[url query] substringFromIndex:[[url query] rangeOfString:@"id="].location+3];

        // 使用本地 ViewController 来显示淘宝商品详情
        TBItemDetailViewController *controller = [[TBItemDetailViewController alloc] initWithItemId:itemId];
        [self.navigationController pushViewController:controller animated:YES];
        [controller release];
    }
}

淘宝 for iOS

现在,淘宝 和 淘宝 HD 两个客户端都支持 taobao:// 协议,来打开特定的链接。目前已经支持的有:
例如,想要在自己的程序中,使用淘宝客户端来显示一个淘宝商品的详情,以支持用户可以直接在 iPhone 上购买,收藏等,就可以使用下面的代码:
- (void)showItemInTaobao4iOS:(NSString *)itemId {
    // 构建淘宝客户端协议的 URL
    NSURL *url = [NSURL URLWithString:[NSString stringWithFormat:@"taobao://item.taobao.com/item.htm?id=%@", itemId]];

    // 判断当前系统是否有安装淘宝客户端
    if ([[UIApplication sharedApplication] canOpenURL:url]) {
        // 如果已经安装淘宝客户端,就使用客户端打开链接
        [[UIApplication sharedApplication] openURL:url];
    } else {
        // 否则使用 Mobile Safari 或者内嵌 WebView 来显示
        url = [NSURL URLWithString:[NSString stringWithFormat:@"http://item.taobao.com/item.htm?id=%@", itemId]];
        [[UIApplication sharedApplication] openURL:url];
    }
}
使用淘宝客户端来打开淘宝链接的好处就是可以让用户更加方便的去购买商品,而不需要再重新登录,或者把用户名密码给了第三方的网站而导致安全隐患。

扩展性

在淘宝客户端中,支持的 URL 往往是淘宝网站已经有的链接,这些链接的 QueryString 中所带的参数往往已经满足了使用本地代码显示内容的需要,但是为了扩展性考虑,就需要添加一些额外的参数,并且与原有 QueryString 中不冲突的参数名称。通过这些额外的参数,再实现客户端打开链接时更多的自定义行为。
例如,如果在打开特定 URL,进行一些操作后需要再返回原来的程序,就会需要在 URL 中添加类似于 callback 这样的参数,这样在客户端处理完用户的操作后,可以将用户操作的结果返回给原来的程序,从而实现程序间的通信。
示例:
- (void)buyItemInTaobao4iOS:(NSString *)itemId {
    // 构建淘宝客户端协议的 URL
    NSString *format = @"taobao://item.taobao.com/item.htm?id=%@&_action=buy&_callback=myapp://taobaobuysuccess";
    NSURL *url = [NSURL URLWithString:[NSString stringWithFormat:format, itemId]];

    // 使用淘宝客户端打开链接
    [[UIApplication sharedApplication] openURL:url];
}
注意:当前淘宝客户端并不支持这样的调用方式,这里仅是一个示例。
当然,在使用这种方式实现程序间通信的时候,需要考虑检查一下来源 URL 的合法性,防止一些非法的调用造成用户的损失。

结语

通过自定义协议地支持,可以将 iOS 程序的一些功能和服务提供给外部程序,也可以实现 Web 和本地应用之间的互相调用。
如果你的 iOS 程序有这些需求的话,那么就可以考虑在 iOS 程序中添加自定义协议的支持了。

2014年2月7日星期五

Windows安全认证是如何进行的?[Kerberos篇]


最近一段时间都在折腾安全(Security)方面的东西,比如Windows认证、非对称加密、数字证书、数字签名、TLS/SSL、WS-Security等。如果时间允许,我很乐意写一系列的文章与广大网友分享、交流。对于很多读者来说,今天讨论的可能是一个既熟悉、又陌生的话题——Windows认证。
目录
一、Kerberos认证简介
二、如何获得“认购权证”?
三、如何通过“认购权证”购买“入场券”?
四、凭票入场

一、Kerberos认证简介

imageWindows认证协议有两种NTLM(NT LAN Manager)和Kerberos,前者主要应用于用于Windows NT 和 Windows 2000 Server(or Later) 工作组环境,而后者则主要应用于Windows 2000 Server(or Later) 域(Domain)环境。Kerberos较之NTLM更高效、更安全,同时认证过程也相对复杂。Kerberos这个名字来源于希腊神话,是冥界守护神兽的名字。Kerberos是一个三头怪兽,之所以用它来命名一种完全认证协议,是因为整个认证过程涉及到三方:客户端、服务端和KDC(Key Distribution Center)。在Windows域环境中,KDC的角色由DC(Domain Controller)来担当。
某个用户采用某个域帐号登录到某台主机,并远程访问处于相同域中另一台主机时,如何对访问者和被访问者进行身份验证(这是一种双向的验证)?这就是Kerberos需要解决的场景。接下来我尽量以比较直白的语言来介绍我所知道的Kerberos认证的整个流程。
Kerberos实际上是一种基于票据(Ticket)的认证方式。客户端要访问服务器的资源,需要首先购买服务端认可的票据。也就是说,客户端在访问服务器之前需要预先买好票,等待服务验票之后才能入场。在这之前,客户端需要先买票,但是这张票不能直接购买,需要一张认购权证。客户端在买票之前需要预先获得一张认购权证。这张认购权证和进入服务器的入场券均有KDC发售。右图(点击看大图)一张图基本揭示了Kerberos整个认证的过程。

二、如何获得“认购权证”?

image首先,我们来看看客户端如何获得“认购权证”。这里的认购权证有个专有的名称——TGT(Ticket Granting Ticket),而TGT的是KDC一个重要的服务——认证服务(KAS:Kerberos Authentication Service)。当某个用户通过输入域帐号和密码试图登录某台主机的时候,本机的Kerberos服务会向KDC的认证服务发送一个认证请求。该请求主要包括两部分内容,明文形式的用户名和经过加密的用于证明访问者身份的Authenticator(我实在找不到一个比较贴切的中文翻译没,Authenticator在这里可以理解为仅限于验证双反预先知晓的内容,相当于联络暗号)。
当KDC接收到请求之后,通过AD获取该用户的信息。通过获取的密码信息生成一个秘钥对Authenticator进行解密。如果解密后的内容和已知的内容一致,则证明请求着提供的密码正确,即确定了登录者的真实身份。
KAS成功认证对方的身份之后,会先生成一个用于确保该用户和KDC之间通信安全的会话秘钥——Logon Session Key,并采用该用户密码派生的秘钥进行加密。KAS接着为该用户创建“认购权证”——TGT。TGT主要包含两方面的内容:用户相关信息和Logon Session Key,而整个TGT则通过KDC自己的密钥进行加密。最终,被不同密钥加密的Logon Session Key和TGT返回给客户端。(以上的内容对应流程图中的步骤1、2)

三、如何通过“认购权证”购买“入场券”?

image经过上面的步骤,客户端获取了购买进入同域中其他主机入场券的“认购凭证”——TGT,以及Logon Session Key,它会在本地缓存此TGT和Logon Session Key。如果现在它需要访问某台服务器的资源,它就需要凭借这张TGT向KDC购买相应的入场券。这里的入场券也有一个专有的名称——服务票据(ST:Service Ticket)。
具体来说,ST是通过KDC的另一个服务TGS(Ticket Granting Service)出售的。客户端先向TGS发送一个ST购买请求,该请求主要包含如下的内容:客户端用户名通过Logon Session Key加密的AuthenticatorTGT和访问的服务器(其实是服务)名
TGS接收到请求之后,现通过自己的密钥解密TGT并获取Logon Session Key,然后通过Logon Session Key解密Authenticator,进而验证了对方的真实身份。
TGS存在的一个根本的目有两点:其一是避免让用户的密码客户端和KDC之间频繁传输而被窃取。其二是因为密码属于Long Term Key(我们一般不会频繁的更新自己的密码),让它作为加密密钥的安全系数肯定小于一个频繁变换得密钥(Short Term Key)。而这个Short Term Key就是Logon Session Key,它确保了客户端和KDC之间的通信安全。
TGS完成对客户端的认证之后,会生成一个用于确保客户端-服务器之间通信安全的会话秘钥——Service Session Key,该会话秘钥通过Logon Session Key进行加密。然后出售给客户端需要的入场券——ST。ST主要包含两方面的内容:客户端用户信息和Service Session Key,整个ST通过服务器密码派生的秘钥进行加密。最终两个被加密的Service Session Key和ST回复给客户端。(以上的内容对应流程图中的步骤3、4)

四、凭票入场

image客户端接收到TGS回复后,通过缓存的Logon Session Key解密获取Service Session Key。同时它也得到了进入服务器的入场券——ST。那么它在进行服务访问的时候就可以借助这张ST凭票入场了。该Serivce Session Key和ST会被客户端缓存。
但是,服务端在接收到ST之后,如何确保它是通过TGS购买,而不是自己伪造的呢?这很好办,不要忘了ST是通过自己密码派生的秘钥进行加密的。具体的操作过程是这样的,除了ST之外,服务请求还附加一份通过Service Session Key加密的Authenticator。服务器在接收到请求之后,先通过自己密码派生的秘钥解密ST,并从中提取Service Session Key。然后通过提取出来的Service Session Key解密Authenticator,进而验证了客户端的真实身份。
实际上,到目前为止,服务端已经完成了对客户端的验证,但是,整个认证过程还没有结束。谈到认证,很多人都认为只是服务器对客户端的认证,实际上在大部分场合,我们需要的是双向验证(Mutual Authentication)——访问者和被访问者互相验证对方的身份。现在服务器已经可以确保客户端是它所声称的那么用户,客户端还没有确认它所访问的不是一个钓鱼服务呢。
为了解决客户端对服务器的验证,服务要需要将解密后的Authenticator再次用Service Session Key进行加密,并发挥给客户端。客户端再用缓存的Service Session Key进行解密,如果和之前的内容完全一样,则可以证明自己正在访问的服务器和自己拥有相同的Service Session Key,而这个会话秘钥不为外人知晓(以上的内容对应流程图中的步骤5、6)
以上的内容仅仅讲述的是基于Kerberos的Windows认证的大体流程,并不涉及到一些细节的东西,比如如何确保时间的同步,如何抵御Replay Attack等。此外,由于本文对Windows底层的知识有限,不能确保所有的内容都是完全正确,如有错误,还往不吝指正。

2014年2月6日星期四

Kerberos简介



Kerberos协议:


Kerberos协议主要用于计算机网络的身份鉴别(Authentication), 其特点是用户只需输入一次身份验证信息就可以凭借此验证获得的票据(ticket-granting ticket)访问多个服务,即SSO(Single Sign On)。由于在每个Client和Service之间建立了共享密钥,使得该协议具有相当的安全性。




条件


先来看看Kerberos协议的前提条件:


如下图所示,Client与KDC, KDC与Service 在协议工作前已经有了各自的共享密钥,并且由于协议中的消息无法穿透防火墙,这些条件就限制了Kerberos协议往往用于一个组织的内部, 使其应用场景不同于X.509 PKI。





过程




Kerberos协议分为两个部分:


1 . Client向KDC发送自己的身份信息,KDC从Ticket Granting Service得到TGT(ticket-granting ticket), 并用协议开始前Client与KDC之间的密钥将TGT加密回复给Client。


此时只有真正的Client才能利用它与KDC之间的密钥将加密后的TGT解密,从而获得TGT。


(此过程避免了Client直接向KDC发送密码,以求通过验证的不安全方式)


2. Client利用之前获得的TGT向KDC请求其他Service的Ticket,从而通过其他Service的身份鉴别。


Kerberos协议的重点在于第二部分,简介如下:









1. Client将之前获得TGT和要请求的服务信息(服务名等)发送给KDC,KDC中的Ticket Granting Service将为Client和Service之间生成一个Session Key用于Service对Client的身份鉴别。然后KDC将这个Session Key和用户名,用户地址(IP),服务名,有效期, 时间戳一起包装成一个Ticket(这些信息最终用于Service对Client的身份鉴别)发送给Service, 不过Kerberos协议并没有直接将Ticket发送给Service,而是通过Client转发给Service.所以有了第二步。


2. 此时KDC将刚才的Ticket转发给Client。由于这个Ticket是要给Service的,不能让Client看到,所以KDC用协议开始前KDC与Service之间的密钥将Ticket加密后再发送给Client。同时为了让Client和Service之间共享那个秘密(KDC在第一步为它们创建的Session Key), KDC用Client与它之间的密钥将Session Key加密随加密的Ticket一起返回给Client。


3. 为了完成Ticket的传递,Client将刚才收到的Ticket转发到Service. 由于Client不知道KDC与Service之间的密钥,所以它无法算改Ticket中的信息。同时Client将收到的Session Key解密出来,然后将自己的用户名,用户地址(IP)打包成Authenticator用Session Key加密也发送给Service。


4. Service 收到Ticket后利用它与KDC之间的密钥将Ticket中的信息解密出来,从而获得Session Key和用户名,用户地址(IP),服务名,有效期。然后再用Session Key将Authenticator解密从而获得用户名,用户地址(IP)将其与之前Ticket中解密出来的用户名,用户地址(IP)做比较从而验证Client的身份。


5. 如果Service有返回结果,将其返回给Client。


总结


概括起来说Kerberos协议主要做了两件事


1. Ticket的安全传递。


2. Session Key的安全发布。


再加上时间戳的使用就很大程度上的保证了用户鉴别的安全性。并且利用Session Key,在通过鉴别之后Client和Service之间传递的消息也可以获得Confidentiality(机密性), Integrity(完整性)的保证。不过由于没有使用非对称密钥自然也就无法具有抗否认性,这也限制了它的应用。不过相对而言它比X.509 PKI的身份鉴别方式实施起来要简单多了。


推荐资料:


Kerberos的原理


Kerberos: An Authentication Service for Computer Networks




Web Services Security系列文章