12/08/2018, 14:34

Tìm hiểu về OpenID

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. Được phát triển bởi tổ chức phi lợi nhuận OpenID Foundation, OpenID cho phép 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 ...

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.

Được phát triển bởi tổ chức phi lợi nhuận OpenID Foundation, OpenID cho phép 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 mỗi website, cho phép 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 mỗi site.

Bạn 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ẽ được 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ó thể kiếm soát được lượng thông tin mà bạn muốn cho phép 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 rất cao.

OpenID nhanh chóng nhận được sự công nhận và sự dụng của cộng đồng web, với hơn 1 tỷ OpenID account đượ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 cho phép 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....

Tại sao nên sử dụng OpenID

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

Với hình ảnh hoạt hình bên cạnh, bạn 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 chính là cách để đị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 lái xe cho toàn bộ Internet vậy. Nhưng còn hơn thế nữa là bởi vì bạn có thể control được thông tin liên kết tới OpenID như là tên của bạn, địa chỉ mail của bạn, và bạn 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 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ần 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ần bảo mật 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 bạn login vào OpenID provider sẽ bảo với các 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 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 bạn thiết lập mình như là người sử dụng OpenID, bất cứ khi nào ai đó nhìn thấy OpenID của bạn được sử dụng, bất cứ nơi nào trên Internet, họ sẽ biết rằng đó chính là bạn. Tương tự như vậy, nếu bạn truy cập vào một trang web 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ó thể gần như chắc chắn 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ả các hoạt động trực tuyến của bạn trở nên 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ỉ hợp nhất thông tin mà bạn đã cho phép public. Bạn 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 hơn or là an toàn hơn so với những gì bạn sử dụng ngay bây giờ. Sự thật là nếu ai đó có được tên truy cập và mật khẩu của OpenID của bạn, họ có thể chiếm đoạt định danh của bạn. Hầu hết các trang web cung cấp việc reset password thông qua email trong trường hợp nếu bạn đã quên nó, có nghĩa là nếu một người nào đó có được tài khoản e-mail của bạn, họ cũng có thể làm giống như trong trường hợp họ có đượ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 trang web mà họ 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à họ 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 ở đâ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 bạn gõ username và pwd, hãy chắc chắn 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 bạn thích, bạn cũng có thể có nhiều OpenID, mỗi 1 cái lại có 1 thông tin khác nhau của bạn. Thực tế là có nhiều webstie cho phép bạn liên kết nhiều OpenID tới cùng 1 account. 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ó 1 username và pwd".

OpenID authentication

OpenID authentication chính là trái tim của OpenID, nó bao hàm 3 concept chính:

  • The OpenID Identifier: Một String xác định duy nhất cho 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 trang web, nhưng nó có thể là một tập tin, hình ảnh, hoặc bất cứ đ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 có thể truy cập nó.

  • The OpenID Provider (OP): Một trang web 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 danh tính của sử dụng RP.

OpenID hoạt động như thế nào?

Giả sử một người dùng đang cố gắng 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 công nhận (bình thường) 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ẽ được 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 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ần "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 có cùng một OpenID. Theo qui định trong OpenID Authentication Specification Version 2.0, OpenID RP có thể giải mã 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 bình thường hóa thành một định danh Claimed Identifier. Hay nói 1 cách khác các định danh được cung cấp bởi người dùng đã được biế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ẽ được normalize thành Claimed Identifier. Trình duyệt của người dùng ("User Agent") sẽ được redirect đến các 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 các chi tiết cụ thể về cách thức 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 các resource an toàn mà user đang cố gắng để 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 điểm đó, 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

Bây giờ 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 hợp với nhau. Đối với phần còn lại của bài viết, tôi sẽ tập trung vào viết một OpenID Relying Party (RP) bằng cách sử dụng thư viện mã nguồn mở openid4java.

Bước đầu tiên trong việc sử dụng OpenID là lấy 1 định danh. Rất dễ ! Chỉ cần 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, 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 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à - Bây giờ 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ó thể build bằng việc cho file WAR vào Tomcat và chạy ở local. Các điểm cần chú ý 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 khi 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 để 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 gian để implement tất cả mọi specs, có thể bạn sẽ được rất thoải mái với việc đó. Đối 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ả các 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.

Danh sách 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ẽ được 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ần 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

Bản 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 độc hại. Một khi người dùng đã chứng minh được danh tính của mình, web sẽ quyết định liệu nên hay 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 bài viết này thực hiện một chức năng khá phổ biến ở nhiều web : Đăng ký thành viên. Nó giả định rằng nếu user có thể chứng minh danh tính của mình thì sau đó user đó sẽ được phép đăng kí. Việc làm này sẽ mô tả cách "trò chuyện" với OP và cách để 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 như thế nào.
  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ị giả mạo.
  6. Proceed to application: RP di chuyển user tới nguồn tài nguyên mà user request ban đầu.

Download source ở đây : http://www.ibm.com/developerworks/library/j-openid/

Write an OpenID Provider for single sign-on authentication

Trong phần trên chúng ta focus chủ yếu vào OpenID Relying Party (RP) - cái có ý nghĩa là các tài nguyên online như 1 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à 1 nửa chặng đường. Phần còn lại của specs về OpenID Authentication là về OpenID Provider (OP). OP hỗ 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 (bao gồm cả myOpenID - là OP cho 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 bài viết), và trong nhiều trường hợp chúng ta ko cần phải xây dựng lại nó. Tuy nhiên có khá 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 hệ thống mạng. Trong trường hợp này, bạn có thể phải thiết lập các hệ thống an toàn - secure, "closed loop". Nó sẽ rất thuận tiện để cho phép người dùng sign in vào tất cả các ứ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ó 1 ứng dụng trong nhóm ứng dụng đó hành động như 1 OP sẽ cho phép bạn set up các single sign-on authentication cho tất cả mọi ứng dụng còn lại.

Trong phần này, chúng ta sẽ focus vào việc viết một OpenID Provider để đảm bảo bảo mật cho một nhóm các ứng dụng trong cấu trúc "closed loop". Chúng ta sẽ bắt đầu với một cái nhìn gần hơn về lợi ích và cấu trúc của một single sign-on authentication , sau đó bước vào coding một OpenID Provider đơn giản cho kiến trúc nhóm. Một lần nữa chúng ta lại sử dụng opendid4java để cung cấp các capabilities core runtime cho xác thực hệ thống và đảm bảo rằng OpenID Provider của 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 kết hợp các ứng dụng có nhiều function khác nhau và có các năng lực lõi khác nhau hơn là build tất cả một function vào một ứ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 đàm phán và làm tăng giá trị của các đề xuất liên quan tới bussiness. Thách thức trong việc phát triển một cụm ứng dụng như vậy chính là authentication. Nó sẽ không làm việc theo kiểu có mỗi authentication cho mỗi user riêng biệt cho mỗi ứ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 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 bảo 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ẽ có được sự thuận tiện bằng việc sign in chỉ 1 lần cho mỗi phiên session. Chúng ta hãy xem xét kỹ hơn các người chơi tham gia vào hệ thống single sign-on authentication ở các mục sau. Chú ý rằng các kiến trúc mà chúng ta thảo luận dưới đâ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ả các ứ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 đích của sample application này là để giải thích cách mà OpenID RP và OP 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 truy cập vào một 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 bao gồm code cho cả 2 bên RP và OP cho nên bạn có thể xem cách nó làm việc cùng nhau. Trong thực tế, bạn sẽ không triển khai đồng thời 2 thành phần này trong cùng 1 ứng dụng, đây chỉ là một sample code cho các bạn tham khảo cách nó tương tác với nhau thôi.

Code listings in the sample app

Danh sách 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 các request từ RP.
  • processAssociationRequest() sử dụng openid4java để kết 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ẽ được 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 để truy cập vào các tài nguyên được bảo vệ từ Relying Party (RP), RP sẽ đảm bảo 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 đích 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 các 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, bạn sẽ nhìn thấy một màn hình với các tài nguyên được bảo vệ trên đó. Các chuỗi sự kiến tiếp theo đó sẽ xay ra, tôi sẽ mô tả chi tiết hơn trong các phần tiếp theo :

  1. Request to access a protected resource: User cố gắng truy cập vào một tài nguyên được bảo vệ trên trang web 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 kết hợp
  3. OP responds to discovery request: OP respond đúng với yêu cầu discovery bằng cách 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ả 2 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 lệ, 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 báo cho RP và gửi bất kì các dữ 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ầu hết các RP sẽ check quyền (authorization) của user trước khi grant access.

Download source ở đây : http://www.ibm.com/developerworks/library/j-openid2/

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

http://openidexplained.com/

http://openid.net/

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

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

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

0