Dịch vụ web RESTful - làm thế nào để xác thực các yêu cầu từ các dịch vụ khác?

Tôi đang thiết kế một dịch vụ web RESTful cần được người dùng truy cập, mà còn các ứng dụng và dịch vụ web khác. Tất cả các yêu cầu đến cần phải được xác thực. Tất cả các giao tiếp diễn ra trên HTTPS. Xác thực người dùng sẽ hoạt động dựa trên mã thông báo xác thực, có được bằng cách ĐĂNG tên người dùng và mật khẩu (qua kết nối SSL) với tài nguyên / phiên do dịch vụ cung cấp.

Trong trường hợp khách hàng sử dụng dịch vụ web, không có người dùng cuối đằng sau dịch vụ khách hàng. Các yêu cầu được bắt đầu bởi các tác vụ theo lịch trình, sự kiện hoặc một số thao tác máy tính khác. Danh sách các dịch vụ kết nối được biết trước (rõ ràng, tôi đoán vậy). Làm cách nào để xác thực những yêu cầu này đến từ các dịch vụ (web) khác? Tôi muốn quá trình xác thực dễ dàng nhất có thể để thực hiện cho các dịch vụ đó, nhưng không phải trả giá bằng bảo mật. Điều gì sẽ là tiêu chuẩn và thực tiễn tốt nhất cho một kịch bản như thế này?

Các tùy chọn mà tôi có thể nghĩ ra (hoặc đã được đề xuất cho tôi):

1. Yêu cầu các dịch vụ khách hàng sử dụng tên người dùng và mật khẩu "giả" và xác thực chúng giống như người dùng. Tôi không thích tùy chọn này - nó không cảm thấy đúng.

2. Chỉ định id ứng dụng vĩnh viễn cho dịch vụ khách hàng, có thể là khóa ứng dụng. Theo như tôi đã hiểu thì điều này cũng giống như có tên người dùng + mật khẩu. Với id và khóa này, tôi có thể xác thực từng yêu cầu hoặc tạo mã thông báo xác thực để xác thực các yêu cầu tiếp theo. Dù bằng cách nào, tôi không thích tùy chọn này, bởi vì bất kỳ ai có thể nắm giữ id ứng dụng và khóa đều có thể mạo danh khách hàng.

3. Tôi có thể thêm một kiểm tra địa chỉ IP vào tùy chọn trước đó. Điều này sẽ làm cho việc thực hiện các yêu cầu giả mạo trở nên khó khăn hơn.

4. Giấy chứng nhận khách hàng. Thiết lập quyền chứng chỉ của riêng tôi, tạo chứng chỉ gốc và tạo chứng chỉ ứng dụng khách cho các dịch vụ khách. Tuy nhiên, có một số vấn đề xuất hiện: a) làm thế nào để tôi vẫn cho phép người dùng xác thực mà không cần chứng chỉ và b) kịch bản này phức tạp đến mức nào khi thực hiện theo quan điểm dịch vụ khách hàng?

5. Một cái gì đó khác - phải có giải pháp khác ngoài đó?

Dịch vụ của tôi sẽ chạy trên Java, nhưng tôi cố tình bỏ qua thông tin về việc xây dựng khung cụ thể nào, bởi vì tôi quan tâm nhiều hơn đến các nguyên tắc cơ bản và không quan tâm nhiều đến các chi tiết triển khai - Tôi giả sử giải pháp tốt nhất cho việc này sẽ có thể thực hiện bất kể khuôn khổ cơ bản. Tuy nhiên, tôi hơi thiếu kinh nghiệm với chủ đề này, vì vậy những lời khuyên và ví dụ cụ thể về việc triển khai thực tế (như thư viện, bài viết hữu ích của bên thứ ba, v.v.) cũng sẽ được đánh giá cao.

Bất kỳ giải pháp cho vấn đề này đều nắm bắt được một bí mật chung. Tôi cũng không thích tùy chọn tên người dùng và mật khẩu được mã hóa cứng nhưng nó có lợi ích là khá đơn giản. Chứng chỉ khách hàng cũng tốt nhưng nó có thực sự khác biệt nhiều không? Có một chứng chỉ trên máy chủ và một trên máy khách. Ưu điểm chính của nó là khó vũ lực hơn. Hy vọng rằng bạn đã có các biện pháp bảo vệ khác để bảo vệ chống lại điều đó.

Tôi không nghĩ rằng điểm A của bạn đối với giải pháp chứng chỉ ứng dụng khách khó giải quyết. Bạn chỉ cần sử dụng một chi nhánh. if (client side certificat) { check it } else { http basic auth }Tôi không phải là chuyên gia java và tôi chưa bao giờ làm việc với nó để làm chứng chỉ phía máy khách. Tuy nhiên, Google nhanh chóng dẫn chúng tôi đến hướng dẫn này có vẻ đúng với con hẻm của bạn.

Bất chấp tất cả các cuộc thảo luận "tốt nhất" này, hãy để tôi chỉ ra rằng có một triết lý khác nói rằng "ít mã hơn, kém thông minh hơn là tốt hơn". (Cá nhân tôi giữ triết lý này). Các giải pháp chứng chỉ ứng dụng khách có vẻ như rất nhiều mã.

Tôi biết bạn đã bày tỏ câu hỏi về OAuth, nhưng đề xuất OAuth2 bao gồm một giải pháp cho vấn đề của bạn được gọi là " mã thông báo mang " phải được sử dụng cùng với SSL. Tôi nghĩ, để đơn giản, tôi sẽ chọn người dùng / pass được mã hóa cứng (một ứng dụng cho mỗi ứng dụng để chúng có thể bị thu hồi riêng lẻ) hoặc mã thông báo mang rất giống nhau.

Sau khi đọc câu hỏi của bạn, tôi sẽ nói, tạo mã thông báo đặc biệt để thực hiện yêu cầu. Mã thông báo này sẽ tồn tại trong thời gian cụ thể (giả sử trong một ngày).

Dưới đây là một ví dụ từ để tạo mã thông báo xác thực:

(day * 10) + (month * 100) + (year (last 2 digits) * 1000)

ví dụ: ngày 3 tháng 6 năm 2011

(3 * 10) + (6 * 100) + (11 * 1000) = 
30 + 600 + 11000 = 11630

sau đó nối với mật khẩu người dùng, ví dụ "my4wgieP4ssword!"

11630my4wesomeP4ssword!

Sau đó thực hiện MD5 của chuỗi đó:

05a9d022d621b64096160683f3afe804

Khi nào bạn gọi một yêu cầu, luôn sử dụng mã thông báo này,

https://mywebservice.com/?token=05a9d022d621b64096160683f3afe804&op=getdata

Mã thông báo này luôn là duy nhất mỗi ngày, vì vậy tôi đoán loại bảo vệ này là quá đủ để luôn bảo vệ dịch vụ của bạn.

Hy vọng giúp

:)

Có một số cách tiếp cận khác nhau mà bạn có thể thực hiện.

1. Những người theo chủ nghĩa RESTful sẽ muốn bạn sử dụng xác thực BASIC và gửi thông tin đăng nhập cho mỗi yêu cầu. Lý do của họ là không ai được lưu trữ bất kỳ nhà nước.

2. Dịch vụ khách hàng có thể lưu trữ cookie, duy trì ID phiên. Cá nhân tôi không thấy điều này gây khó chịu như một số người theo chủ nghĩa thuần túy mà tôi nghe thấy - việc xác thực hết lần này đến lần khác có thể tốn kém. Dường như bạn không quá thích ý tưởng này.

3. Từ mô tả của bạn, có vẻ như bạn có thể quan tâm đến OAuth2 Trải nghiệm của tôi cho đến nay, từ những gì tôi đã thấy, đó là loại khó hiểu và loại cạnh chảy máu. Có những triển khai ngoài kia, nhưng chúng rất ít. Trong Java, tôi hiểu rằng nó đã được tích hợp vào các mô-đun bảo mật của Spring3 . ( Hướng dẫn của họ được viết rất hay.) Tôi đã chờ xem liệu sẽ có phần mở rộng trong Restlet hay không , nhưng cho đến nay, mặc dù nó đã được đề xuất và có thể nằm trong lồng ấp, nhưng nó vẫn chưa được kết hợp đầy đủ.

Tôi tin rằng cách tiếp cận:

1. Yêu cầu đầu tiên, khách hàng gửi id / mật mã
2. Trao đổi id / pass cho mã thông báo duy nhất
3. Xác thực mã thông báo trên mỗi yêu cầu tiếp theo cho đến khi hết hạn

là khá chuẩn, bất kể bạn thực hiện như thế nào và các chi tiết kỹ thuật cụ thể khác.

Nếu bạn thực sự muốn đẩy phong bì, có lẽ bạn có thể coi khóa https của khách hàng ở trạng thái tạm thời không hợp lệ cho đến khi thông tin xác thực được xác thực, giới hạn thông tin nếu chúng không bao giờ và cấp quyền truy cập khi chúng được xác thực, dựa trên hết hạn.

Hi vọng điêu nay co ich

Theo như cách tiếp cận chứng chỉ ứng dụng khách, sẽ không quá khó để thực hiện trong khi vẫn cho phép người dùng không có chứng chỉ ứng dụng khách.

Nếu trên thực tế bạn đã tạo ra Cơ quan chứng nhận tự ký của riêng mình và cấp chứng nhận khách hàng cho mỗi dịch vụ khách hàng, bạn sẽ có một cách dễ dàng để xác thực các dịch vụ đó.

Tùy thuộc vào máy chủ web bạn đang sử dụng, cần có một phương pháp để chỉ định xác thực ứng dụng khách sẽ chấp nhận chứng chỉ ứng dụng khách, nhưng không yêu cầu chứng chỉ. Ví dụ: trong Tomcat khi chỉ định trình kết nối https của bạn, bạn có thể đặt 'clientAuth = muốn', thay vì 'true' hoặc 'false'. Sau đó, bạn sẽ đảm bảo thêm chứng chỉ CA tự ký vào cửa hàng tin cậy của mình (theo mặc định tệp cacerts trong JRE bạn đang sử dụng, trừ khi bạn chỉ định một tệp khác trong cấu hình máy chủ web của mình), vì vậy các chứng chỉ tin cậy duy nhất sẽ được cấp CA tự ký của bạn.

Về phía máy chủ, bạn sẽ chỉ cho phép truy cập vào các dịch vụ mà bạn muốn bảo vệ nếu bạn có thể truy xuất chứng chỉ ứng dụng khách từ yêu cầu (không phải null) và vượt qua bất kỳ kiểm tra DN nào nếu bạn muốn bảo mật hơn. Đối với người dùng không có máy khách, họ vẫn có thể truy cập dịch vụ của bạn, nhưng đơn giản là sẽ không có chứng chỉ nào trong yêu cầu.

Theo tôi đây là cách 'an toàn' nhất, nhưng chắc chắn nó có đường cong học tập và chi phí hoạt động, vì vậy có thể không nhất thiết là giải pháp tốt nhất cho nhu cầu của bạn.

5. Cái gì khác - phải có giải pháp khác ngoài đó?

Bạn nói đúng, có đấy! Và nó được gọi là JWT (JSON Web Tokens).

Mã thông báo web JSON (JWT) là một tiêu chuẩn mở (RFC 7519) xác định một cách nhỏ gọn và khép kín để truyền thông tin an toàn giữa các bên dưới dạng đối tượng JSON. Thông tin này có thể được xác minh và tin cậy vì nó được ký điện tử. JWT có thể được ký bằng cách sử dụng một bí mật (với thuật toán HMAC) hoặc cặp khóa công khai / riêng bằng RSA.

Tôi rất khuyên bạn nên tìm hiểu về JWTs. Chúng là một giải pháp đơn giản hơn nhiều cho vấn đề khi so sánh với các giải pháp thay thế.

https://jwt.io/int sinhtion /

Bạn có thể tạo Phiên trên máy chủ và chia sẻ sessionIdgiữa máy khách và máy chủ với mỗi lệnh gọi REST.

1. Đầu tiên xác thực yêu cầu REST : /authenticate. Trả về phản hồi (theo định dạng máy khách của bạn) với sessionId: ABCDXXXXXXXXXXXXXX;

2. Lưu trữ này sessionIdtrong Mapphiên thực tế. Map.put(sessionid, session)hoặc sử dụng SessionListenerđể tạo và hủy khóa cho bạn;

   public void sessionCreated(HttpSessionEvent arg0) {
     // add session to a static Map 
   }
   
   public void sessionDestroyed(HttpSessionEvent arg0) {
     // Remove session from static map
   }
   

3. Nhận sessionid với mọi cuộc gọi REST, như URL?jsessionid=ABCDXXXXXXXXXXXXXX(hoặc cách khác);

4. Lấy lại HttpSessiontừ bản đồ bằng cách sử dụng sessionId;
5. Xác thực yêu cầu cho phiên đó nếu phiên hoạt động;
6. Gửi lại phản hồi hoặc thông báo lỗi.

Tôi sẽ sử dụng để ứng dụng chuyển hướng người dùng đến trang web của bạn với tham số id ứng dụng, khi người dùng chấp thuận yêu cầu tạo mã thông báo duy nhất được ứng dụng kia sử dụng để xác thực. Bằng cách này, các ứng dụng khác không xử lý thông tin đăng nhập của người dùng và các ứng dụng khác có thể được thêm, xóa và quản lý bởi người dùng. Foursquare và một vài trang web khác xác thực theo cách này và rất dễ thực hiện như các ứng dụng khác.

Bên cạnh xác thực, tôi đề nghị bạn nghĩ về bức tranh lớn. Xem xét thực hiện dịch vụ RESTful phụ trợ của bạn mà không cần bất kỳ xác thực nào; sau đó đặt một số xác thực rất đơn giản yêu cầu dịch vụ lớp giữa giữa người dùng cuối và dịch vụ phụ trợ.