Tomcat:Error filterStart,怎么看错误日志?

启动tomcat最怕遇到Filter,listener启动错误。因为Tomcat 不会记录任何更多的错误信息,你都不知道是哪个引起的错误!

这是由于Tomcat使用java.util.logging的缘故,要想获得更多错误信息,需要在默认包名下(就是最终的WEB-INF/classes目录下)放置logging.properties文件,加上这么几句话即可:

org.apache.catalina.core.ContainerBase.[Catalina].level = INFO
org.apache.catalina.core.ContainerBase.[Catalina].handlers = java.util.logging.ConsoleHandler

 

Tomcat这方面让人很恼火!

Continue reading Tomcat:Error filterStart,怎么看错误日志?

ISOC 以及 W3C

常常听说的是IETF,IRTF,W3C, 还真搞不清楚是什么关系,下面是关于ISOC的结构说明:

国际互联网并不为任何政府部门或组织所拥有或控制。它的技术 — 操作规则的实际制定者是一个自发的组织 —Internet 协会(ISOC)。Internet 协会(ISOC)拥有几个下属组织,由它们去执行各种任务。Internet 架构委员会(IAB)成员的任命主要由 Internet 协会(ISOC)从 IETF 和其它的提名委员会所作出的提名中确定。

Internet 架构委员会(IAB)是 Internet 协会(ISOC)的技术顾问组织,其任务包括:任命 IETF 主席和 IESG 的候选人、担任仲裁委员会,管理各种内容的编辑和发行(如 RFC)。

Internet 域名和地址分配公司(ICANN)是一个技术协调机构,履行如下事务:

  • 管理 Internet 域名
  • 管理 IP 地址
  • 管理 协议参数和端口号
  • 确保国际互联网骨干服务器系统的稳定运行

Internet 工程指导小组(IESG)获得了 ISOC 的特许,它可以对 IETF 的各项事务进行技术层面上的管理并提供各种 Internet 的标准程序。IESG 管理着 IETF 的工作小组并直接负责从某种 Internet 规范形成 Internet 标准过程中的相关活动,包括登记、按照 “ 标准步骤 ” 进行办理、及最终的确认。

Internet 研究任务组(IRTF)需要为 Internet 协议、应用程序、架构和技术的长期开发组建团队。

Internet 工程任务组(IETF)是一个大型的、开放的国际团体,由本行业的网络设计人员组成,制定 Internet 技术规范。在请求注解(RFC)中, TCP/IP 协议和其它许多协议都得到了充分的论证和足够的资料,而请求注解正是由 IETF 委员会进行起草、论证、发行并敲定的。所有的文件都是公开、免费的,而且都可以从 IETF 网站的参考列表中查找出来。

请求注解(RFC)是有关 Internet 的一系注解和文件。RFC 讨论的内容包括运算和计算机通信的诸多方面,重点在于网络协议、过程、程序和理念,但也会包括一些会议记录、观点,有时还会含有幽默。由 Internet 工程任务组(IETF)及其指导小组 IESG 共同制定的 Internet 协议套的规范文档就被当作 RFC 进行发行。许多 TCP/IP 和 PPP 协议都得到了 RPC 的充分论证和文档支持。

国际互联网组织:ISOC、IAB、IETF、ICANN、IESG 和 IRTF

W3C则又是另外一个组织,主要关注的是web方面,比如html,xml等。

ISOC是和整个因特网相关的,他的关注面要大一些。

Continue reading ISOC 以及 W3C

VPN 和 VLAN 关系

VPN它可以通过特殊的加密的通讯协议在连接在Internet上的位于不同地方的两个或多个企业内部网之间建立一条专有的通讯线路,就好比是架设了一条专线一样,但是它并不需要真正的去铺设光缆之类的物理线路。

VLAN是指在交换局域网的基础上,采用网络管理软件构建的可跨越不同网段、不同网络的端到端的逻辑网络。

VPN可以防止外部直接获取数据,VLAN则可以隔离同一局域网不同VLAN之间的通信。

可以在VPN的基础上划分VLAN。

Continue reading VPN 和 VLAN 关系

IPSec更安全这句话!

看到一本书上这样一句话,IPv6提供网络层上的加密,因此具有更高的安全性。

依据语境,这是指的IPSec的网络层加密功能,相比的是SSL的传输层加密。

那么网络层加密为什么就比传输层安全呢?依据我的理解,数据发送从上到下,ssl发给传输层及以下的数据已经是加密的,这个不存在什么缺点。

网上搜了一下,倒是有这么个观点:SSL VPN比IPSec VPN更安全

所以我说,这书上“IPSec更安全”这句话还是谈正确的!

Continue reading IPSec更安全这句话!

itsnat -- Custom components and friendly URLs

中文版:itsnat--自定义控件入门和友好的url

itsnat  is a interesting java web framework, which implemented TBITS(The Browser Is The Server ), it mocks a Universal W3C Java Browser in the server, the client send the client browser's action to the server by AJAX, then mapping them to W3C Java Dom action, the DOM in the server response with the action and send result to the client, the client use the result to synchronize the DOM in the client browser with the server DOM with javascript, really wonderful idea, right?


To design a custom component, need flowing steps:(these code will create a custom Dialog component)

1: Add Listener to the Template

Java code: 

>String html = "E:/projects/ItsNat/wb/test/WebRoot/apps/pto/frontpage.html"; ItsNatDocumentTemplate docTemplate = getItsNatHttpServlet().registerItsNatDocumentTemplate("pto","text/html", html); docTemplate.addItsNatServletRequestListener(new ItsNatServletRequestListener(){

Continue reading itsnat -- Custom components and friendly URLs

【转】安全的session管理

好文章,转载以备份。原文出自这里

 

前言

session 的管理對網站應用程式非常的重要,不適當或不夠嚴謹的管理也會造成安全上的問題,以下針對 session 管理相關的安全問題分項探討。

 

使用 Framework 內建的 Session Manager

藉由 session 限制與維護使用者的行為是網路安全很重要的一環。大多數的人會使用網站應用程式框架內建的 session 管理,有些人會使用 Perl CGI。網站開發者應盡量避免自行開發 session 管理,因為自行開發常常會藏有許多漏洞,而框架內建的 session 管理經過多次測試與修復相對上較為安全。此外這些框架會持續維護其安全性,因此要確保做好更新與安裝修補程式的動作。

  • 密碼強度
    Session handler 的一個重點是 session token 或 session ID 的密碼強度,Session handler 產生的 token 必須是無法預知並且長度夠長讓人無法猜測的到。Session tokens 必須每個使用者都不同、無法預測、能抵抗反向工程。
  • 適當的 Key Space
    一個加密的演算法也可能因為 Key space 不夠大造成攻擊者使用暴力解來取得內容。因此 token 的 Key space 必須足夠大來防禦暴力攻擊法,並且注意電腦計算能力與寬頻能力已隨著時代進步。
  • Session Identifier(session ID)
    Session Identifier 應該使用最大可用的 character set,如果一個 session ID 要由 8 characters of 7 bits 組成,有效密鑰長度為56位,但如果使用的 character set 只有整數可用 4 bits表示,有效密鑰長度就只有32位。因此一個好的 session ID 應盡量使用越多 characters 越好,但一些特殊字元有轉譯的麻煩,所以大多的 frameworks 採用 A-Z 和 0-9 有些還添加了小寫 a-z。

驗證由客戶端傳來的 Session ID

所有由客戶端傳來的資料都必須經過編碼和驗證,許多 frameworks 會驗證和編碼從 GET 和 POST 而來的 input,但未充分編碼從客戶端 cookie 傳來的 session ID 值。下面的 ESAPI code 片段使用 ESAPI 中的 method 來驗證 session ID 的值:

public String getRequestedSessionId() {
     String id = request.getRequestedSessionId();
     String clean = " ";
     try {
          clean = ESAPI.validator().getValidInput( "Requested cookie: " + id, id, "HTTPJSESSIONID", 50, false );
     } catch (ValidationException e ) {
          // already logged
     }
     return clean;
 }

 

 

確保 idle 和 timeouts 時間夠短

根據業務需求和安全性的考量,session 必須有一有限的壽命,在一定時間後過期。網站應用程式必須將靜止一段時間的 session 設為過期,刪除此 session 並一併更改 session cookie 的內容。

 

在使用者登出後銷毀 session

當使用者登出後網站應用程式需讓 session 無效或者移除此 session,並且如果隨後有別的使用者登入必須取得不同的 session ID。要做到這樣的機制,當使用者 logout 時必須改寫 session cookies 註明已過期並銷毀 session。以下是 ESAPI code 的例子:

public void logout() {
     ESAPI.httpUtilities().killCookie( ESAPI.currentRequest(), ESAPI.currentResponse(), HTTPUtilities.REMEMBER_TOKEN_COOKIE_NAME );

     HttpSession session = ESAPI.currentRequest().getSession(false);
     if (session != null) {
          session.invalidate();
     }
     ESAPI.httpUtilities().killCookie(ESAPI.currentRequest(), ESAPI.currentResponse(), "JSESSIONID");
     loggedIn = false;
     logger.info(Logger.SECURITY, "Logout successful" );
     ESAPI.authenticator().setCurrentUser(User.ANONYMOUS);
}

 

 

public void killCookie(HttpServletRequest request, HttpServletResponse response, String name) {
     String path = "//";
     String domain=" ";
     Cookie cookie = ESAPI.httpUtilities().getCookie(request, name);
     if ( cookie != null ) {
          path = cookie.getPath();
          domain = cookie.getDomain();
     }
     SafeResponse safeResponse = new SafeResponse( response );
     safeResponse.addCookie(name, "deleted", 0, domain, path);
}

 

輪換 Session ID

對於高安全性網站,網站應用程式在處理重要的程序之前,或是經過某一段時間和幾次 requests 後,必須重新產生 session ID。中等或低等的網站,在使用者權限改變時也應該重新產生 session ID ,例如從訪客變成登入的會員或從登入者變成管理者。以下是 ESAPI code 重新產生 Session ID 的例子:

public HttpSession changeSessionIdentifier(HttpServletRequest request) throws AuthenticationException {

     // get the current session
     HttpSession session = request.getSession();

     // make a copy of the session content
     Map temp = new HashMap();
     Enumeration e = session.getAttributeNames();
     while (e != null && e.hasMoreElements()) {
          String name = (String) e.nextElement();
          Object value = session.getAttribute(name);
          temp.put(name, value);
     }

     // kill the old session and create a new one
     session.invalidate();
     HttpSession newSession = request.getSession();

     // copy back the session content
     Iterator i = temp.entrySet().iterator();
     while (i.hasNext()) {
          Map.Entry entry = (Map.Entry) i.next();
          newSession.setAttribute((String) entry.getKey(), entry.getValue());
     }
     return newSession;
}

 

 

保護 Session ID

如果可以的話,網站應用程式應該都以 HTTPS 的方式傳輸。如果無法,至少包含敏感性資料的頁面或處理程序要使用 HTTPS; 如果 HTTPS 無法保護整個網站的 session,在 HTTPS 傳輸時必須搭配 session ID,將此 session ID 和網站伺服器的 session 做配對檢查。

如果必須藉由 URL 參數來傳遞 session ID 時,必須使用 POST。如果 cookies 用來儲存並由 HTTPS 傳送 session ID 時,必須被設為”安全”這樣就不會經過 non-SSL 的管道。

網站應用程式必須提供登出的機制,並確保登出後此 session 過期和被銷毀。

 

作者列表

  1. 2011/03/21 姚辰旻 初稿

參考資料

 

PS:

ESAPI的站点都访问不了?

Continue reading 【转】安全的session管理

【转】Lustre 介绍

http://book.51cto.com/art/201004/196350.htm

Lustre[5]文件系统是一个基于对象存储的分布式文件系统,并且与PVFS一样,Lustre也是一个开源项目。Lustre项目与1999 年在Carnegie Mellon University启动,现在已经发展成为应用最广泛的分布式文件系统。Lustre已经运行在当今世界上最快的集群系统里面,比如Bule Gene,Red Storm等计算机系统,用来进行核武器相关的模拟,以及分子动力学模拟等等非常关键的领域。

Lustre的组织结构在其官方文档中有详细的介绍,如图 5.5所示,Lustre集群组件包含了MDS(元数据服务器)、MDT(元数据存储节点)、OSS(对象存储服务器)、OST(对象存储节点)、Client(客户端),以及连接这些组件的高速网络。

1)元数据存储与管理。MDS负责管理元数据,提供一个全局的命名空间,Client可以通过MDS读取到保存于MDT之上的元数据。在 Lustre中MDS可以有2个,采用了Active-Standby的容错机制,当其中一个MDS不能正常工作时,另外一个后备MDS可以启动服务。 MDT只能有1个,不同MDS之间共享访问同一个MDT。

(点击查看大图)图 5.5  Lustre集群架构

2)文件数据存储与管理。OSS负载提供I/O服务,接受并服务来自网络的请求。通过OSS,可以访问到保存在OST上的文件数据。一个OSS对应 2到8个OST,其存储空间可以高达8TB。OST上的文件数据是以分条的形式保存的,文件的分条可以在一个OSS之中,也可以保存在多个OSS中。 Lustre的特色之一是其数据是基于对象的职能存储的,跟传统的基于块的存储方式有所不同。

3)Lustre系统访问入口。Lustre通过Client端来访问系统,Client为挂载了Lustre文件系统的任意节点。Client提供了Linux下VFS(虚拟文件系统)与Lustre系统之间的接口,通过Client,用户可访问操作Lustre系统中的文件。

Lustre集群中的各个节点通过高速的以太网或Quadrics Elan、Myrinet等多种网络连接起来。

(点击查看大图)图 5.6  Lustre文件系统架构

在Lustre官方手册中给出了Lustre文件系统的架构,如图 5.6所示。Lustre文件系统也是一个3方架构,包括了MDS、OSS和Client这3个模块。文件的打开(open)和关闭(close)、元数据以及并发访问控制都在Client和MDS之间进行;文件I/O操作以及文件锁在OSS和Client之间进行;文件备份,文件状态获取以及文件创建等在MDS和OSS之间进行。目前Lustre文件系统最多可以支持100000个Client,1000个OSS 和2个MDS节点。

同PVFS类似,Lustre系统中既可以运行一个功能模块,也可以同时运行2个或3个功能模块,这取决于系统的规模。不过Lustre一般运行于高性能计算机系统之上,为了提高Lustre文件系统的性能,通常MDS、OSS和Client是分开运行在Lustre不同的节点之上的。

实验与应用已经证明,Lustre文件系统的性能和可扩展性都不错。不仅如此,Lustre文件系统还拥有基于对象的智能化存储、安全的认证机制、比较完善的容错机制等优点,值得注意的是,Lustre还实现了部分文件锁。Lustre确保从不同Client端挂载的Lustre文件系统看到的都是一个单一的、同步的、一致的命名空间。由于Lustre部分锁机制的存在,多个Client端在同一时间点可以写同一文件的不同区域,其它Client则可以读取文件的其它区域。由于部分文件锁的存在,极大的提高了多用户对同一文件进行并发访问时系统的性能,对同一文件并发访问这在像数据库这种应用里是极为常见的。

相对于PVFS,Lustre的可用性和扩展性以及性能上都有较大的提高。然而,Lustre需要特殊设备的支持,并且Lustre目前还没实现 MDS的集群管理,虽然相比PVFS的单MDS,Lustre的双MDS在可用性上还是提高不少,但是当系统达到一定的规模之后,MDS还是很有可能成为 Lustre系统中的瓶颈。

Continue reading 【转】Lustre 介绍

【转】Ari Zilka谈Ehcache的进程内堆外缓存BigMemory

转自infoq,文章不错,而且译得也不错。

Ari Zilka谈Ehcache的进程内堆外缓存BigMemory

作者 Srini Penchikala 译者 王丽娟 发布于 2010年11月29日

Ehcache的BigMemory提供了一个进程内的堆外缓存,用来存储应用相关的大批量数据。Terracotta上周发布了BigMemory模块的GA版本,该模块支持Ehcache企业版。BigMemory是Ehcache标准API的一部分,为cache定义两个新属性(overflowToOffHeap和maxMemoryOffHeap)就可以使用了,代码片段如下所示:

<cache name="sample-offheap-cache"
    maxElementsInMemory="10000"
    eternal="true"
    memoryStoreEvictionPolicy="LRU"
    overflowToOffHeap="true"
    maxMemoryOffHeap="1G"/>

BigMemory在内存存储策略上有别于传统的缓存解决方案。它不把数据存储在Java堆里,从而避免了JVM的GC问题。BigMemory这种特别的存储被称为堆外(Off-Heap)存储。传统的缓存解决方案为了规避这些问题,都将数据分布在缓存节点组成的集群上。BigMemory提供了一种新的架构选择方案,允许应用运行在堆小于1G的JVM上,利用堆外的内存来加快数据访问的速度。

InfoQ有幸采访了Terracotta的CTO Ari Zilka,请他谈了Ehcache框架里的BigMemory新特性、BigMemory有助于应用性能提升的用例场景,以及BigMemory的局限性。

InfoQ:为Ehcache框架添加BigMemory特性的主要动机是什么?

主要动机是为了解决我们在Terracotta服务器里遇到的GC问题。服务器里的GC会引起响应时间和大规模GC事件出现变化,可能会致使(一级缓存L1的)缓存客户端故障转移到备份的Terracotta服务器上去。我们意识到这个解决方案的好处后就立即扩大了它的应用范围,包括为独立Ehcache追加一个内存存储,这个内存存储后来就发展成了BigMemory——Ehcache企业版的一个插件。

InfoQ:BigMemory堆外存储提供的方式能避免Java GC的复杂性,你能谈一谈实现的具体细节么?

BigMemory把缓存对象存储在Java堆之外,但仍然在操作系统的Java进程里。所以它仍然是个进程内的缓存,具备所有与此相关的高性能,但它不使用堆,这样就可以给应用配置很小的堆空间,从而避免GC问题。BigMemory使用了JDK 1.4引入的DirectByteBuffers。所有的Java实现都可以运行BigMemory,所以任何人都可以使用BigMemory,而不用更换JDK。

操作系统内存管理器的功能差不多就要完成了。届时我们会在放入数据时分配内存、移除数据时释放内存,我们能做这些事情是因为BigMemory是个缓存,而不是一般用途的Java程序。DirectByteBuffers分配内存很慢,但用起来非常快。所以我们会在启动的时候就从操作系统获取所有需要的内存。

BigMemory的关键之处在于,怎样判断某个对象不再被使用、关联的内存被释放了,这也是很多人一开始最难理解的地方。对缓存来说,这其实非常简单。Map主要涉及put、get和remove操作。我们在放入数据的时候分配内存(malloc),移除数据的时候释放内存(free)。我们实现了一个内存管理器,它使用的是很好理解的计算机科学算法,还有我们专门为此实现的增强。

在被问及BigMemory什么情况下能提升应用性能时(从只读、经常读、读写操作来说),Ari回答说,在“90%读/10%写”的常见情况和“50%读/50%写”的写操作过多的情况下,他们都见过比较好的性能结果。这是因为缓存是进程内的。只读操作会受到分布式缓存的影响。读取活跃数据集要比读取其它数据快很多,那些不活跃的数据必须通过网络获取。

InfoQ:BigMemory解决方案有什么局限性?

鉴于BigMemory是纯Java的、进程内的,而且和常见的JVM、容器兼容,所以它没有明显的局限性。我们找到的最大的内存盒有384GB内存,我们在上面测试的结果显示,在BigMemory始终有350GB内存的空闲情况下,性能都是线性的,没有明显的增长。

我们要向用户强调的限制只有一个,那就是使用堆外存储的话,放置在BigMemory中的对象必须进行序列化。对通常就存储在缓存里的那些数据来说,这并不是什么问题。

一旦对象被序列化,在返回Java堆的时候必需反序列化才可以使用。这确实是一笔性能开销。因此在没有GC的时候,BigMemory会比堆内存储慢。但BigMemory还是要比底层可用的存储快很多,不论是本地磁盘、网络存储,还是RDBMS等原本记录数据的系统。

还应指出的是,序列化/反序列化的性能开销远没有很多用户想象的那么大。BigMemory已经针对字节缓冲区做了优化,本身也包含一些优化机制,可以对使用标准Java序列化的对象进行优化。举例来说,测试版发布之后添加的那些优化机制能使复杂Java对象的性能提升两倍,使byte数组的性能提升四倍。Terracotta Server Array正是用byte数组存储数据的。用自定义的序列化则能进一步减少性能开销。

InfoQ问Ari,架构师和开发人员在应用中使用BigMemory时应该注意哪些最佳实践和问题。Ari回答说,任何成功的商业应用都要处理伸缩性问题。缓存是最稳妥、最容易实现的解决方案之一。现在比较新颖的是,不用非得引入缓存集群了。

最好的做法就是用新眼光来审视一下你的性能架构,看你能否从大型的进程内缓存获益。BigMemory可以让架构师对服务器和进程密度进行优化,以满足特定的需求,而不用受制于Java的局限性。

最大的问题则是大多数人已经针对Java本身的局限性做了优化。比如说,大多数Ehcache用户会运行32位的JVM。根据OS的不同,32位 Java的地址空间会是2到4GB不等。所以这些用户在用Java时就放弃了使用很多内存。应用目前可能都运行在RAM很小的硬件上。所以用户要是想使用 BigMemory来运行100GB的进程内缓存,可能就意味着要更换新的硬件,即便现在硬件很便宜。

InfoQ:Ehcache框架以后的路线图是怎样的?BigMemory有什么特殊的么?

我们正在开发Ehcache和Terracotta的下一个版本(代码以澳大利亚弗里曼特尔的别称Freo命名),计划本月发布测试版。我们计划在这个版本中添加一系列功能特性和性能增强。比如Ehcache Search,它能让Ehcache用户在缓存里进行搜索,就像使用数据库一样。Ehcache Search已经发布了测试版,文档也已经全部可用了。

至于BigMemory,我们还在继续提升性能,同时会增加一系列比较实用的增强,例如提供更多的工具,帮助人们更好地理解最适合他们用例的设置。

查看英文原文:Ari Zilka on Ehcache BigMemory

---------------------------------------

PS:

另外一篇:http://www.infoq.com/interviews/zilka-bigmemory

Terracotta是一款由美国Terracotta公司开发的著名开源Java集群平台。

参见:http://blog.csdn.net/ansonchan/article/details/1873001

这有个人问的问题:

    请教老马,这个产品在当前有没有成功又稳定的项目中使用的经验,由于该项目中使用大量自旋竞争锁操作,导致cpu偏高,所以带来的稳定性一直是个问题

问的有水平。哪些人用了?

Continue reading 【转】Ari Zilka谈Ehcache的进程内堆外缓存BigMemory

串口为什么比并口快以及IDE容量

教科书上说,并口一次传多位,速度快。但是实际上为什么SATA硬盘比IDE/PATA硬盘要快?

两方面的原因:

1:数据同步问题

网上有个例子很形象:

并口啊
举个很切合实际的例子
有10个人走一个门,如果门大可以同时通过,门小要单一同过
大门=并口,小门=串口
10个人排一列不容易跟丢,说明串口适合远距离
10个人排一行,可能会走丢,适合近距离,但是走大门能一下通过,速度快,并口的特点 

这是说多个位同时传送,长时间传送后,有些位先到,有些位后到,这就要取决于最后到的那位了,还要加上数据校验的时间(比特流传输的速度必须减缓以纠正错误)。

2:干扰问题

10个人并排走,这个人把那个人推一下,几个人交头接耳说笑话,-----这说的是互相之间的干扰。

目前并行总线没有能解决好数据干扰问题,所以还要校错。

对于长距离传输,问题一影响较大,对于硬盘,问题二影响较大。

Continue reading 串口为什么比并口快以及IDE容量

OpenID 入门

wiki百科:  http://zh.wikipedia.org/wiki/OpenID

官网: http://openid.net/  规范:http://openid.net/developers/specs/

这篇文章较适入门:  http://www.theserverside.com/news/1364125/Using-OpenID 作者也是open4javba的作者。

使用open4java,wicket

http://www.ibm.com/developerworks/cn/java/j-openid/

下  http://www.ibm.com/developerworks/cn/java/j-openid2/index.html?ca=drs-cn-0427

讲得最明白的还是google: http://code.google.com/intl/zh-CN/apis/accounts/docs/OpenID.html

http://www.seven2.com.cn/archives/786/  Google OAUTH + OpenID 解决方案

open4java 用起来总是报错,说什么xml解析错误,查了半天原来是xml解析包冲突,遇到这种情况要检查一下别的引用是否有冲突的xml解析包。

使用0.9.6 maven一直下载不下来改用0.9.5就可以了。

运行simple-openid这个示例只需要这样的pom:

<project xmlns="http://maven.apache.org/POM/4.0.0"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>test</groupId>
	<artifactId>test</artifactId>
	<version>0.0.1-SNAPSHOT</version>
	<dependencies>		
		<dependency>
			<groupId>org.openid4java</groupId>
			<artifactId>openid4java</artifactId>
			<version>0.9.5</version>
		</dependency>
	</dependencies>	
</project>

简单复述一遍流程:

用户登陆网站(简称A),A提供选择:

1:用A的账户登陆。

2:用google的账户登陆。

用户想“俺有个google openid账户,我不想重新注册A账户”。他就选择用google openid账户登陆。

A站点就要知道google的openid provider endpoint的url,向这个地址请求,这一步叫discovery.

endpoint会返回一个文档(可能是xrds格式或html格式),例如google返回的xrds格式:

<?xml version="1.0" encoding="UTF-8"?>
<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)">
  <XRD>
  <Service priority="0">
  <Type>http://specs.openid.net/auth/2.0/server</Type>
  <Type>http://openid.net/srv/ax/1.0</Type>
  <Type>http://specs.openid.net/extensions/ui/1.0/mode/popup</Type>
  <Type>http://specs.openid.net/extensions/ui/1.0/icon</Type>
  <Type>http://specs.openid.net/extensions/pape/1.0</Type>
  <URI>

https://www.google.com/accounts/o8/ud</URI>
</Service>
</XRD>
</xrds:XRDS>

可以看到uri里面就是下一步进行认证的地址。

A就要向这个uri请求认证,这个里面要设置一些参数用来进行交互比如说交换用户信息(AX),或是简单注册(Sreg)。当然要传入用户输入的openid账号。以及验证成功后接受google信息的url(openid.return_to)。google验证完成后会请求openid.return_to设置的网址,如果成功,会将需要的用户信息使用参数传入。

在这最后一步需要验证返回是否是安全的(中途是否被修改):

1:检查openid.return_to和请求的地址是否匹配;

2:检查discovery信息。

3:检查openid.response_nonce

4:检查签名

------------------------------------------

我再使用规范2.0的复述一遍:

1 The end user initiates authentication by presenting a User-Supplied Identifier to the Relying Party via their User-Agent. 

用户向RP提交openid.

2 After normalizing the User-Supplied Identifier, the Relying Party performs discovery on it and establishes the OP Endpoint URL that the end user uses for authentication. It should be noted that the User-Supplied Identifier may be an OP Identifier, as discussed in Section 7.3.1, which allows selection of a Claimed Identifier at the OP or for the protocol to proceed without a Claimed Identifier if something else useful is being done via an extension.

RP使用openid执行discovery操作。openid中包含了将要请求的OP地址相关信息。OP对discovery返回的信息中包含了OP Endpoint 信息,下一步将要使用这些信息。openid还可能仅仅是OP的标识符而不是用户的openid标识符。

3 (optional) The Relying Party and the OP establish an association -- a shared secret established using Diffie-Hellman Key Exchange [RFC2631]. The OP uses an association to sign subsequent messages and the Relying Party to verify those messages; this removes the need for subsequent direct requests to verify the signature after each authentication request/response.

关联,密钥交换,这一步不是必需的,但是如果使用了这一步,那么最后的验证(7)就不是必需的。

4 The Relying Party redirects the end user's User-Agent to the OP with an OpenID Authentication request.

RP跳转用户到OP的登陆页面。

5 The OP establishes whether the end user is authorized to perform OpenID Authentication and wishes to do so. The manner in which the end user authenticates to their OP and any policies surrounding such authentication is out of scope for this document.

OP完成对用户的验证

6 The OP redirects the end user's User-Agent back to the Relying Party with either an assertion that authentication is approved or a message that authentication failed.

OP跳转用户到RP提供的returnto页面,并提供验证信和其他扩展属性。

7 The Relying Party verifies the information received from the OP including checking the Return URL, verifying the discovered information, checking the nonce, and verifying the signature by using either the shared key established during the association or by sending a direct request to the OP.

RP验证返回的信息是否可靠。(如果使用了association这一步,那么就不需要。因为直接可以通过交换的密钥来验证返回。)

-----------------

要认识到openid和cas的sso是两种风格,openid对于不同公司不同网站,典型的登陆操作是,即使用户已经登陆了provider的网站,但是即使他再打开consumer的网站,consumer网站任然是不知道此用户已经登陆的。用户想要登录consumer网站,还需要进入登陆页面,这个时候给予用户使用provider网站账户登陆的选项。用户选择使用provider网站账户登陆后,由consumer的网站自动与provider网站交互完成登录过程。典型的例子可看 http://translate.uservoice.com/ 中的google登录方式。

但是如果是同一个公司,不同的网站,要通过openid实现类似CAS的方式,也是可行的,每个网站都使用过滤器来检查用户是否已经在主站(provider)登陆,将用户信息拿过来就行了。即discovery这一步是固定的。

 

==========================================

参考:

http://r-j-r-a5438-163-com.iteye.com/blog/611351

http://www.360doc.com/content/08/0507/11/7349_1242557.shtml

http://code.google.com/p/openid4java/w/list

http://code.google.com/p/openid-server/

Continue reading OpenID 入门

Pagination


Total views.

© 2013 - 2020. All rights reserved.

Powered by Hydejack v6.6.1