OpenID là gì

OpenID là một tiêu chuẩn mở và là một giao thức authen được phân cấp.

Bạn Đang Xem: Tìm hiểu về OpenID

Được phát triển bởi tổ chức phi lợi nhuận OpenID Foundation, OpenID được chấp nhận user có thể được authen bởi rất nhiều website ( Relying Parties hoặc RP) sử dụng service của bên thứ 3. Nó giảm được việc phái thiết lập riêng logic sign up/login cho từng website, được chấp nhận các user có thể login tới nhiều webstie ko hề liên quan tới nhau mà ko cần phải có những định danh và password riêng cho từng site.

Chúng ta có thể chọn việc liên kết thông tin với OpenID của bạn – thông tin này sẽ tiến hành share tới các website mà bạn đã truy cập ( ví dụ như tên or mail của bạn ). Với OpenID, bạn cũng có thể kiếm soát được lượng thông tin mà bạn muốn được chấp nhận các website bạn đến thăm biết được.

Với OpenID, chỉ duy nhất identity provider quản lý password, và provider này sẽ confirm identity của bạn tới các website mà bạn đến thăm, ko có một website nào có thể biết được password của bạn – đây là một yếu tố bảo mật thông tin rất cao.

OpenID nhanh chóng nhận được sự xác nhận và sự dụng của cộng đồng web, với trên 1 tỷ OpenID tài khoản được thiết lập và 50,000 webstie sử dụng phương thức OpenID để login. Một vài tổ chức lớn được chấp nhận hoặc phát hành OpenIDs or tái sử dụng lại OpenID ví dụ như Google, Facebook, Yahoo!, Microsoft, AOL, MySpace, Sears, Universal Music Group, France Telecom, Novell, Sun, Telecom Italia v.v….

Vì sao nên sử dụng OpenID

Đăng kí thành viên nhanh và dễ dàng

Với hình ảnh phim hoạt hình bên cạnh, bạn cũng có thể hình dung sự tiện lợi này. Một người thu tiền hỏi anh khách hàng muốn đăng kí thành viên cho Food-Mart ko ? và khách hàng trả lời rất hào hứng “Nope. Tôi sẽ sử dụng OpenID của tôi”. Một OpenID đây chính là phương pháp để định danh chính bạn ko quan trọng bạn ghé thăm website nào. Nó như kiểu là bằng tài xế cho toàn bộ Internet vậy. Nhưng còn hơn thế nữa là bởi vì bạn cũng có thể control được thông tin liên kết tới OpenID như là tên gọi của bạn, địa chỉ mail của bạn, và bạn cũng có thể chọn website nào được quyền thấy nó ? cái nào ko ? Điều này cũng đồng nghĩa với việc những website sử dụng OpenID sẽ ko hỏi đi hỏi lại bạn your name, your mail address lần nào thì cũng vậy.

Login nhanh và dễ dàng

OpenID also simplifies signing in. OpenID còn rất dễ dàng để login. Với OpenID bạn chỉ có nhớ 1 username và 1 password. Bởi vì bạn login vào website với OpenID của bạn, cho nên bạn chỉ có bảo mật thông tin với OpenID là đủ rồi. Password này của bạn thực tế là chỉ được quản lý bởi OpenID provider của bạn, ko phải là các website bạn đang login, khi chúng ta login vào OpenID provider sẽ bảo với những website đó là bạn đang login đấy và bạn là ai. Ko có bất kì một website nào nhìn được password của bạn, cho nên bạn ko cần phải quá bận tâm về vấn đề bảo mật thông tin khi sử dụng OpenID.

Tiếp cận đến khái niệm “web identity”

Bởi vì OpenID định danh bạn là duy nhất trên Internet, một khi chúng ta thiết lập mình như thể người sử dụng OpenID, bất kì khi nào ai đó nhìn thấy OpenID của bạn được sử dụng, bất kì nơi nào trên Internet, họ sẽ biết rằng đó đây chính là bạn. Tương tự như vậy, nếu khách hàng truy cập vào trong 1 website mới và thấy rằng một người nào đó với OpenID của bạn bạn, bạn cũng có thể gần như kiên cố rằng đó là bạn của bạn. Điều đó có thể khiến bạn lo lắng rằng OpenID là sẽ làm cho tất cả những hoạt động trực tuyến của bạn trở thành quá rõ ràng và dễ dàng bị phát hiện. Hãy yên tâm, mặc dù OpenID thống nhất thông tin về bạn, nhưng nó chỉ thống nhất thông tin mà bạn đã được chấp nhận public. Chúng ta có thể chọn, sử dụng OpenID, thông tin nào ? và thông tin đó ai sẽ thấy được

Liệu OpenID có an toàn?

OpenID là thực sự cũng ko kém bảo mật thông tin hơn or là an toàn hơn so với những gì bạn sử dụng ngay lúc này. Sự thực là nếu ai đó đạt được tên truy cập và mật khẩu của OpenID của bạn, họ có thể cướp đoạt định danh của bạn. Hồ hết các website cung cấp việc reset password thông qua email trong trường hợp nếu khách hàng đã quên nó, có tức là nếu một người nào đó đạt được tài khoản e-mail của bạn, họ cũng có thể có thể làm giống như trong trường hợp họ đạt được tên truy nhập và mật khẩu của OpenID của bạn. Họ có thể kiểm tra các website mà người ta nghĩ rằng bạn có một tài khoản và yêu cầu thay mật khẩu bị quên. Tương tự như vậy, nếu một ai đó có quyền truy cập vào OpenID của bạn, họ có thể tìm kiếm trên Internet đến những nơi mà người ta nghĩ rằng bạn có tài khoản và đăng nhập như bạn … không có gì khác biệt về bảo mật thông tin ở đây.

Cho nên, ko liên quan đến việc bạn sử dụng OpenID hay ko, bạn nên cẩn thận về tài khoản của bạn – username và pwd. Khi chúng ta gõ username và pwd, hãy kiên cố ràng bạn đang ở trên website mà bạn nghĩ là bạn muốn vào

Có nên giao toàn bộ định danh cho chỉ 1 website?

Tùy bạn, nếu khách hàng thích, bạn cũng có thể có thể có nhiều OpenID, mỗi 1 cái lại có một thông tin khác nhau của bạn. Thực tế là có nhiều webstie được chấp nhận bạn liên kết nhiều OpenID tới cùng 1 tài khoản. Nhưng việc làm này sẽ phá hỏng khái niệm đơn giản hóa của “chỉ có một username và pwd”.

OpenID authentication

OpenID authentication đây chính là trái tim của OpenID, nó khái quát 3 concept chính:

• The OpenID Identifier: Một String xác định duy nhất cho tất cả những người sử dụng.

• The OpenID Relying Party (RP): Một nguồn tài nguyên trực tuyến (có thể là một website, nhưng nó có thể là một tập tin, hình ảnh, hoặc bất kì điều gì bạn muốn kiểm soát quyền truy cập vào) có sử dụng OpenID để xác định những người dân có thể truy cập nó.

• The OpenID Provider (OP): Một website mà người sử dụng có thể yêu cầu một OpenID và sau đó đăng nhập và xác thực tính danh của sử dụng RP.

OpenID hoạt động ra làm sao?

Xem Thêm : Ủy viên bộ chính trị là gì? [2023]

Giả sử một người dùng đang cố gắng nỗ lực truy cập tài nguyên là một phần RP của website, và RP sử dụng OpenID. Để truy cập vào các nguồn tài nguyên, người sử dụng phải xuất trình OpenID của mình trong một form có thể được xác nhận (thường nhật) như OpenID. OpenID được mã hóa với vị trí của OP. RP sau đó lấy định danh của người dùng và chuyển hướng người dùng đến OP, nơi đó user sẽ tiến hành yêu cầu để chứng minh yêu cầu của mình sử dụng ID đó.

Hãy cùng điểm qua các thành phần cụ thể chi tiết của OpenID và mỗi vài trò của nó trong cả quá trình xử lý.

OpenID Identifiers

Trái tim của OpenID là các OpenID Identifier. Một OpenID Identifier (hoặc chỉ có “Identifier” là đủ) là một String unique các ký tự xác định duy nhất một người nào đó. Không có hai người dân có cùng một OpenID. Theo qui định trong OpenID Authentication Specification Version 2.0, OpenID RP có thể lời giải một định danh để xác định được để xác thực người dùng. Trong cơ chế hoạt động của OpenID, có 2 định danh cần quan tâm :

• User-Supplied Identifier
• Claimed Identifier

Như tên tên của nó đã thể hiện, một định danh User-Supplied Identifier là định danh được cung cấp bởi user tới RP. Các định danh User-Supplied Identifier phải được thường nhật hóa thành một định danh Claimed Identifier. Hay nói một cách khác các định danh được cung cấp bởi người dùng đã được chuyển đổi thành một dạng chuẩn. Các định danh Claimed Identifier sau đó có thể được sử dụng để xác định OP thông qua một quá trình được gọi là phát hiện, sau đó OP sẽ xác thực người dùng.

OpenID Relying Party

RP được trình bày với một định danh User-Supplied Identifier, định danh này sẽ tiến hành normalize thành Claimed Identifier. Trình duyệt của người dùng (“User Agent”) sẽ tiến hành redirect đến những OP để người dùng có thể nhập mật khẩu và được xác thực.

RP không biết và cũng không quan tâm đến những cụ thể chi tiết cụ thể về phương pháp một định Claimed Identifier được xác thực. Nó chỉ muốn biết liệu các OP đã xác thực thành công người dùng hay chưa ? Nếu đã đc xác thực rồi, User Agent được redirect đến những resource an toàn mà user đang cố gắng nỗ lực để truy cập. Nếu người dùng không thể xác thực, RP từ chối ko cho truy cập.

Open ID Provider (OP)

Các OP, hoặc OpenID Provider chịu trách nhiệm phát hành Identifiers và thực hiện xác thực user. Các OP cũng cung các cơ chế quản lý dựa trên Web của OpenID. Các OP thu thập và giữ thông tin cơ bản sau đây về mỗi người dùng:

• E-mail address
• Full name
• Date of birth
• Postal code
• Country
• Primary language

Khi một OP được hỏi để xác thực định danh Claimed Identifier, trình duyệt của người dùng được dẫn đến một trang đăng nhập để user nhập mật khẩu. Tại thời gian đó, quyền kiểm soát là OP. Nếu người dùng được xác thực thành công, sau đó OP chỉ dấn các trình duyệt đến một vị trí được xác định bởi RP ( “return-to” URL). Nếu người dùng không thể xác thực, anh/cố ta thể sẽ nhận được một tin nhắn từ OP rằng quá trình xác thực của họ thất bại.

Becoming an OpenID Relying Party

Hiện nay bạn dã biết về các thành phần chính của OpenID và làm thế nào để kết phù hợp với nhau. So với phần còn sót lại của nội dung bài viết, tôi sẽ tập trung vào viết một OpenID Relying Party (RP) bằng phương pháp sử dụng thư viện mã nguồn mở openid4java.

Bước trước hết trong việc sử dụng OpenID là lấy 1 định danh. Rất dễ ! Chỉ việc vào myOpenID và nhấn nút SIGN UP FOR AN OPENID. Chọn một OpenID như redneckyogi hoặc jstevenperry. Form đăng ký sẽ cho bạn biết liệu userid bạn đã chọn đã được sử dung hay ko. Nếu chưa ai dùng, các bạn sẽ được hướng dẫn để nhập mật khẩu, địa chỉ e-mail, một vài text trong JCaptcha v.v….

Vài phút sau các bạn sẽ nhận được một e-mail chưa URL. Truy cập vào URL để xác nhận địa chỉ e-mail của bạn và – Hiện nay bạn có một OpenID!

About the sample application

Như tôi đã nói ở trên, tôi đã viết một ứng dụng Web Java sử dụng openid4java để tạo ra một OpenID Relying Party (RP). Nó là một ứng dụng đơn giản mà bạn cũng có thể build bằng việc cho file WAR vào Tomcat và chạy ở local. Những điểm cần lưu ý trong sample application này :

• User nhập OpenID vào trang đăng kí
• Application sẽ verifies Identifier ( direct user tới OP để sign in )
• Sau khoản thời gian xác thực thành công, ứng dụng lấy thông tin của người dùng từ các OP, và hướng người dùng đến một trang Save page, nơi user có thể confirm và lưu thông tin của mình. The information displayed on the Save page is pulled from the information available from the OP.
• Các thông tin hiển thị trên Save page lấy từ các thông tin có sẵn từ các OP.
• Tôi đã viết các ứng dụng sử dụng Wicket. Nhưng tôi đã cố gắng nỗ lực để giảm thiểu để giúp đỡ bạn focus vào việc học cơ chế của OpenID Relying Party.

Cấu trúc của sample code được chia thành 2 chức năng lớn

• User interface được sử dụng Wicket
• OpenID authentication — sử dụng openid4java library

About openid4java and the sample application code

Các spec về OpenID Authentication khá phức tạp. Nếu ban có thời kì để implement tất cả mọi specs, có thể các bạn sẽ được rất thoải mái với việc đó. So với tôi, tôi là người khá lười biếng cho nên tôi đã chọn sử dụng thư viện openid4java. openid4java là một implementation tất cả những specs của OpenID Authentication nơi mà nó sẽ rất dễ dàng hơn nhiều để sử dụng OpenID trong việc lập trình.

List code phía sau sẽ show các API mà openid4java gọi một RP để sử dụng OpenID.

Để giảm thiêu các sự rối loạn với Wicket trong sample application, tôi sẽ tách biệt phần code gọi openid4java trong class RegistrationService (đặt trong com.makotogroup.sample.model). Class này chứa 5 methods tương ứng với việc sử dụng openid4java API:

• getReturnToUrl() trả về một URL mà trình duyệt sẽ tiến hành direct đến khi mà authen thành công.
• getConsumerManager() được sử dụng để get một instance của class openid4java API. class này sẽ handle tất cả mọi code sample RP để thực hiện quá trình authen.
• performDiscoveryOnUserSuppliedIdentifier() handles bất ki một vấn đề gì xẩy ra trong quá trình xử lý.
• createOpenIdAuthRequest() tạo nên các constuct AuthRequest cấp thiết trong quá trình authen.
• processReturn() handles xử lý các kết quả tra về từ các request authen.

Writing the RP

Thực chất của authen là để user cung cấp cho website identity của họ. Việc làm này bảo vệ việc truy cập các tài nguyên của Web từ các truy cập không mong muốn hoặc ô nhiễm và độc hại. Một khi người dùng đã chứng minh được tính danh của mình, web sẽ quyết định liệu nên hay là không để cấp cho user đó quyền truy cập vào các nguồn tài nguyên.

The sample application for this article performs a function common to many Web sites: user registration. It assumes that if the user can prove his identity then he is allowed to register. It’s a simple premise, but it will demonstrate how a typical “conversation” with the OP goes and how to use openid4java to do it. Here are the basic steps: Sample application trong nội dung bài viết này thực hiện một chức năng khá phổ quát ở nhiều web : Đăng ký thành viên. Nó giả thiết rằng nếu user có thể chứng minh tính danh của mình thì sau đó user này sẽ được phép đăng kí. Việc làm này sẽ mô tả cách “trò chuyện” với OP và phương pháp để sử dụng openid4java để làm điều đó. Các bước cơ bản như sau:

1. Obtain the User-Supplied Identifier: The RP lấy OpenID của user.
2. Discovery: RP sẽ normalize User-Supplied Identifier để quyết định sẽ connect tới loại OP nào cho việc authen và connect ra làm sao.
3. Association: Bước này là optional nhưng rất khuyến khích thêm vào xử lý. Đây là bước thiết lập channel secure kết nối giữa RP và OP.
4. Authentication request: RP yêu cầu OP authen cho user.
5. Verification: RP yêu cầu userid verification từ phía OP và đảm bảo quá trình giao tiếp ko bị mạo.
6. Proceed to application: RP vận chuyển user tới nguồn tài nguyên mà user request lúc đầu.

Tải về source ở đây : http://www.ibm.com/developerworks/library/j-openid/

Write an OpenID Provider for single sign-on authentication

Xem Thêm : Làm thế nào để rèn luyện phản xạ tiếng Anh nhanh chóng, hiệu quả?

Trong phần trên tất cả chúng ta focus chủ yếu vào OpenID Relying Party (RP) – cái có ý tức là các tài nguyên trực tuyến như một web site or MP3 sử dụng OpenID cho đăng kí hoặc xác thực. Tuy nhiên đó cũng mới chỉ là một trong nửa phần đường. Phần còn sót lại của specs về OpenID Authentication là về OpenID Provider (OP). OP tương trợ người dùng trong việc yêu cầu một OpenID và xác thực người dùng đó trong quá trình login vào các tài nguyên web tuẩn theo cơ chế OpenID.

Rất nhiều các nhà cung cấp OpenID đã tồn tại (gồm có cả myOpenID – là OP cho khối hệ thống đăng ký ứng dụng Java Web chúng tôi đã đề câp trong các phần trên của nội dung bài viết), và trong nhiều trường hợp tất cả chúng ta ko cần phải xây dựng lại nó. Tuy nhiên có rất nhiều kịch bản / yêu cầu khiến bạn phải build riêng OP của bạn. Đây là kiểu một cụm các ứng dụng nơi mà một vài ứng dụng share tài nguyên trong khối hệ thống mạng. Trong trường hợp này, bạn cũng có thể phải thiết lập các khối hệ thống an toàn – secure, “closed loop”. Nó sẽ rất thuận tiện để được chấp nhận người dùng sign in vào tất cả những ứng dụng trong một lúc thay vì phải đăng nhập vào từng ứng dụng riêng biệt. Và lúc đó, có một ứng dụng trong nhóm ứng dụng đó hành động như một OP sẽ được chấp nhận bạn set up các single sign-on authentication cho tất cả mọi ứng dụng còn sót lại.

Trong phần này, tất cả chúng ta sẽ focus vào việc viết một OpenID Provider để đảm bảo bảo mật thông tin cho một nhóm các ứng dụng trong cấu trúc “closed loop”. Tất cả chúng ta sẽ khai mạc với một chiếc nhìn gần hơn về lợi ích và cấu trúc của một single sign-on authentication , sau đó lấn sân vào coding một OpenID Provider đơn giản cho kiến trúc nhóm. Một lần nữa tất cả chúng ta lại sử dụng opendid4java để cung cấp các capabilities core runtime cho xác thực khối hệ thống và đảm nói rằng OpenID Provider của tất cả chúng ta sẽ tuân theo specs của OpenID Authentication.

Single sign-on authentication

Trong một kịch bản nào đó – thường là trong business, nó sẽ rất ý nghĩa hơn bằng việc phối hợp các ứng dụng có nhiều function khác nhau và có những năng lực lõi khác nhau hơn là build tất cả một function vào trong 1 ứng dụng. Kiểu nhóm ứng dụng này thường là trung tâm trái tim của B2B, nơi các đối tác mang lại cái gì đó trên bàn thương thuyết và làm tăng giá trị của nhiều đề xuất liên quan tới bussiness. Thử thách trong việc phát triển một cụm ứng dụng như vậy đây chính là authentication. Nó sẽ không còn thao tác làm việc theo phong cách có mỗi authentication cho từng user riêng biệt cho từng ứng dụng; ít nhất là không phải là từ góc nhìn của người dùng cuối. Trong một khối hệ thống nhóm sử dụng chuẩn OpenID cho authentication, mỗi đối tác ứng dụng đảm nhận authentication tới các OP. Mỗi ứng dụng được đảm nói rằng quá trình truy cập vào các chức năng của nó và tài nguyên của nó là secure, và end-user sẽ đạt được sự thuận tiện bằng việc sign in chỉ 1 lần cho từng phiên session. Tất cả chúng ta hãy xem xét kỹ hơn các người chơi tham gia vào khối hệ thống single sign-on authentication ở các mục sau. Lưu ý rằng các kiến trúc mà tất cả chúng ta thảo luận ở đây được build dựa trên sample application trong chương trên.

Open ID Relying Party (RP)

Một OpenID Relying Party, là các tài nguyên Web or là bản thân Web site mà yêu cầu secure khi truy cập vào các contents đó. Một RP sử dụng OpenID Provider (OP) để authen user. RP có thể sử dụng extension Simple Registration (SReg) và / hoặc Attribute Exchange (AX) để yêu cầu đăng kí or identify thông tin về user. RP tạo nên các request về SReg và AX khi mà nó yêu cầu OP authen cho user thông qua việc gọi đến thư viện openid4java.

Open ID Provider (OP)

OpenID Provider cung cấp authentication cho tất cả những ứng dụng đối tác. Một khi người dùng đc authen thành công thông qua việc gọi đến thư viện openid4java, OP sẽ đáp ứng các yêu cầu SReg và AX từ phía RP.

About the sample application

Mục tiêu của sample application này là để giảng giải cách mà OpenID RP và OP thao tác làm việc với nhau để bảo vệ các nguồn tài nguyên khỏi các truy cập trái phép.

• User cố gắng nỗ lực truy cập vào trong 1 nguồn tài nguyên được bảo vệ
• RP yêu cầu OP authen User
• OP authen user trong trường hợp user chưa login
• RP quyết định liệu cho cấp quyền truy cập các tài nguyên cho user đó ko

Sample application gồm có code cho tất cả hai bên RP và OP cho nên bạn cũng có thể xem cách nó thao tác làm việc cùng nhau. Trong thực tế, các bạn sẽ không triển khai song song 2 thành phần này trong cùng 1 ứng dụng, đây chỉ là một sample code cho những bạn tham khảo cách nó tương tác với nhau thôi.

Code listings in the sample app

List các code trong phần này sẽ mô tả cách openid4java gọi một OP (và RP ) để sử dụng OpenID. OpenIdProviderService.java chứa một vài methods tương ứng với việc sử dụng các API của openid4java.

• getServerManager() config và trả về các tham chiếu đến class ServerManager của openid4java.
• getOpEndpointUrl() trả về Endpoint URL nơi mà OP nhận thêm những request từ RP.
• processAssociationRequest() sử dụng openid4java để phối hợp OP theo yêu cầu của RP.
• sendDiscoveryResponse() gửi một yêu cầu discovery tới RP.
• createAuthResponse() tạo các message AuthResponse của openid4java cái mà sẽ tiến hành gửi tới RP cùng với yêu cầu xác thực.
• buildAuthResponse() là method core xử lý các requests OpenID Simple Registration và Attribute Exchange.

Để build ứng dụng này, chạy Ant [REF] và build WAR target, sau đó copy file WAR vào thư mục webapps của Tomcat và start Tomcat.

OpenID authentication: Step by step

Khi user cố gắng nỗ lực để truy cập vào các tài nguyên được bảo vệ từ Relying Party (RP), RP sẽ đảm nói rằng user mà anh/cô ta nói là ai (authentication) và sau đó quyết định có grant access cho ko (authorization). Mục tiêu của phần này là authen cho nên nếu user được authen bởi OpenID Provider (OP), sample app sẽ grant access cho những tài nguyên được bảo vệ. Trong thực tế, RP cũng sẽ thực hiện các chức năng kiểu như authorization nữa.

Khi chạy các sample app, các bạn sẽ nhìn thấy một màn hình hiển thị với những tài nguyên được bảo vệ trên đó. Các chuỗi sự kiến tiếp theo này sẽ xay ra, tôi sẽ mô tả cụ thể chi tiết hơn trong các phần tiếp theo :

1. Request to access a protected resource: User cố gắng nỗ lực truy cập vào trong 1 tài nguyên được bảo vệ trên website của RP.
2. RP performs discovery: RP gửi yêu cầu discovery tới OP đê thiết lập connection và thực hiện phối hợp
3. OP responds to discovery request: OP respond đúng với yêu cầu discovery bằng phương pháp send back một XRDS (eXtensible Resource Descriptor Sequence) thông qua extension SReg, Attribute Exchange (AX), hoặc OpenID Provider Authentication Policy (AP). Các XRDS sẽ confirm OP là nhà cung cấp dịch vụ OpenID của người dùng.
4. RP requests user authentication: RP check với OP để xem người dùng đã có thể đc chứng thực hay chưa ? Nếu login thành công, RP sử dụng SReg, AX hoặc cả hai extension đó để request thông tin về user.
5. OP authenticates user: Nếu user chưa đăng nhập hoặc có một session ko hợp thức, anh ta sẽ yêu cầu được cung cấp thông tin đăng nhập của mình. Nếu xác thực thành công, OP thông tin cho RP và gửi bất kì các tài liệu được request thông qua SReg hoặc/và AX.
6. RP grants access: User được grant access tới các tài nguyên được bảo vệ. Trong thực tế hồ hết các RP sẽ check quyền (authorization) của user trước lúc grant access.

Tải về source ở đây : http://www.ibm.com/developerworks/library/j-openid2/

Nguồn tham khảo & dịch tổng hợp

http://openidexplained.com/

OpenID

https://en.wikipedia.org/wiki/OpenID

http://www.ibm.com/developerworks/library/j-openid/

http://www.ibm.com/developerworks/library/j-openid2/