Tài nguyên, phạm vi, quyền và chính sách trong keycloak

82

Tôi muốn tạo một hệ thống kiểm soát truy cập dựa trên vai trò khá đơn giản bằng cách sử dụng hệ thống ủy quyền của Keycloak. Hệ thống mà Keycloak đang thay thế cho phép chúng tôi tạo một "người dùng", là thành viên của một hoặc nhiều "nhóm". Trong hệ thống kế thừa này, người dùng được cấp "quyền" để truy cập từng "khả năng" thông qua tư cách thành viên nhóm (nơi các nhóm được chỉ định quyền) hoặc cấp quyền trực tiếp cho người dùng.

Tôi muốn ánh xạ hệ thống kế thừa thành ủy quyền keycloak.

Đối với tôi, sẽ đơn giản để ánh xạ từng "khả năng" trong hệ thống hiện có thành một tài nguyên keycloak và một tập hợp các phạm vi keycloak. Ví dụ: khả năng "viewAccount" rõ ràng sẽ ánh xạ tới tài nguyên "tài khoản" và phạm vi "chế độ xem"; và "viewTransaction" ánh xạ tới một tài nguyên "giao dịch" ... nhưng cách tốt nhất là chỉ tạo một phạm vi "xem" và sử dụng nó trên nhiều tài nguyên (tài khoản, giao dịch, v.v.)? Hay tôi nên tạo phạm vi "viewAccount", phạm vi "viewTransaction", v.v.?

Tương tự, tôi hơi bối rối về quyền. Đối với mỗi sự kết hợp thực tế của tài nguyên và phạm vi, thông thường bạn có tạo một quyền không? Nếu có nhiều quyền phù hợp với một tài nguyên / phạm vi nhất định, Keycloak sẽ làm gì? Tôi đoán rằng mục đích của Keycloak là cho phép tôi định cấu hình ma trận quyền đối với tài nguyên và phạm vi, vì vậy, ví dụ: tôi có thể có quyền truy cập "tài khoản" và quyền đối với phạm vi "xem", vì vậy tôi sẽ có quyền để xem tài khoản?

Tôi hỏi vì kết quả của tất cả những điều này dường như là khả năng "viewAccount" cũ của tôi kết thúc việc tạo tài nguyên "Tài khoản", với phạm vi "Chế độ xem" và quyền "viewAccount", điều này dường như đưa tôi trở lại vị trí cũ. Cái nào tốt, nếu nó chính xác.

Cuối cùng, rõ ràng là tôi cần một bộ chính sách xác định xem có nên áp dụng viewAccount hay không. Nhưng tôi nói đúng rằng điều này có nghĩa là tôi cần một chính sách cho từng nhóm kế thừa mà người dùng có thể thuộc về? Ví dụ: nếu tôi có vai trò "bộ phận trợ giúp", thì tôi cần chính sách "tư cách thành viên bộ phận trợ giúp", sau đó tôi có thể thêm chính sách này vào quyền "viewAccount". Điều này có chính xác?

Cảm ơn,

dấu

permissions  keycloak 
— Bác sĩ Eval
nguồn
26
Keycloak trông giống như một hệ thống khá trưởng thành và rất có năng lực, nhưng những gì nó thực sự có thể làm vẫn là một bí ẩn vì dường như có quá nhiều câu hỏi và quá ít câu trả lời. Tôi thực sự đang tự hỏi mình tất cả các câu hỏi trong bài đăng của bạn và không thể tìm thấy bất kỳ câu trả lời nào. Tại sao không có hướng dẫn tốt ngoài đó? Không có ai thực sự sử dụng công cụ này? Hay không ai thèm viết về nó?
— Stijn de Witt,
3
Keycloak đang làm việc rất tốt cho chúng tôi trong việc sản xuất (cho đến nay) ngoại trừ ủy quyền, điều này thực sự khó liên quan đến các vấn đề thực tế của tôi. Nhưng tôi đồng ý, có rất nhiều tài liệu về cách Keycloak thực hiện OIDC, nhưng cũng có một giả định phổ biến rằng chúng ta biết OAuth và OIDC. Thật khó để liên hệ Keycloak với các vấn đề ứng dụng nếu bạn chưa biết về OIDC, nhưng đối với tôi Keycloak là phần giới thiệu về OIDC, điều này hơi hấp dẫn 22. (Picketlink / Picketbox thậm chí còn tệ hơn!). Tôi thấy rằng tải xuống và chỉ chơi với nó, là tốt nhất.
— Bác sĩ Đánh giá
6
đồng ý về những ý kiến, tài liệu keycloak và sử dụng các trường hợp hút
— Olivier Refalo
20
Các nhà phát triển Keycloak, hãy lưu ý câu hỏi này! Tài liệu của bạn khá tốt, nhưng nó cần thêm hướng dẫn giải quyết các câu hỏi được nêu ra ở đây. Bạn cũng có thể cân nhắc việc chuyển từ danh sách gửi thư của trường cũ sang một thứ gì đó thân thiện với người dùng hơn một chút như diễn đàn hoặc chỉ Stackoverflow.
— GGGforce
5
Câu trả lời muộn nhưng tất cả các giả định của bạn về cơ bản là đúng. Về cách thực hành tốt nhất là gì, tôi nghĩ rất khó để nói vì khả năng này còn rất mới. Không chắc liệu ngay cả các nhà phát triển kc có biết những phương pháp hay nhất tại thời điểm này hay không.
— cen

Câu trả lời:

120

Tôi biết mình đã trễ hơn 2 năm nhưng tôi nghĩ tôi sẽ chia sẻ những gì tôi biết và hy vọng sẽ giảm bớt phần nào nỗi đau cho độc giả trong tương lai. Hoàn toàn minh bạch- Tôi hoàn toàn không phải là chuyên gia về Keycloak / OAuth / OIDC và những gì tôi biết chủ yếu là từ việc đọc tài liệu, sách, hay trên YouTube và chơi với công cụ này.

Bài đăng này sẽ bao gồm hai phần:

  1. Tôi sẽ cố gắng trả lời tất cả các câu hỏi của bạn trong khả năng tốt nhất của tôi
  2. Tôi sẽ chỉ cho bạn tất cả cách bạn có thể sử dụng các chính sách / phạm vi / quyền trong Keycloak mà không cần triển khai một ứng dụng riêng biệt để hiểu rõ hơn một số khái niệm cốt lõi trong chuỗi này. Xin lưu ý rằng điều này chủ yếu là để giúp bạn bắt đầu. Tôi đang sử dụng Keycloak 8.0.0.

Phần I

Một số thuật ngữ trước khi chúng ta bắt đầu:

  • Trong Keycloak, bạn có thể tạo 2 loại quyền: dựa vào tài nguyên và Phạm vi-Based .
  • Nói một cách đơn giản, đối với Resource-Basedquyền, bạn áp dụng nó trực tiếp vào tài nguyên của mình
  • Đối với Scoped-Basedquyền, bạn áp dụng nó cho (các) phạm vi hoặc (các) phạm vi và tài nguyên của bạn.

cách tốt nhất là chỉ tạo một phạm vi "chế độ xem" và sử dụng nó trên nhiều tài nguyên (tài khoản, giao dịch, v.v.)? Hay tôi nên tạo phạm vi "viewAccount", phạm vi "viewTransaction", v.v.?

Phạm vi đại diện cho một tập hợp các quyền tại một tài nguyên được bảo vệ. Trong trường hợp của bạn, bạn có 2 tài nguyên: accountvà transaction, vì vậy tôi sẽ nghiêng về cách tiếp cận thứ hai.

Về lâu dài, có một thế giới viewphạm vi liên quan đến mọi nguồn lực của bạn (ví dụ như account, transaction, customer,settlement ...) làm cho phép khó khăn cho cả quản lý và thích ứng với những thay đổi yêu cầu an ninh.

Dưới đây là một vài ví dụ mà bạn có thể xem qua để cảm nhận về thiết kế

Tuy nhiên, hãy lưu ý - tôi không tuyên bố rằng bạn không nên chia sẻ phạm vi giữa các tài nguyên. Vấn đề thực tế, Keycloakcho phép điều này đối với các tài nguyên giống nhau type. Ví dụ, bạn có thể cần cả hai viewAccountvà viewTransactionphạm vi để đọc một giao dịch trong một tài khoản nhất định (sau cùng, bạn có thể cần quyền truy cập vào tài khoản để xem các giao dịch). Yêu cầu và tiêu chuẩn của bạn sẽ ảnh hưởng rất nhiều đến thiết kế của bạn.

Đối với mỗi sự kết hợp thực tế của tài nguyên và phạm vi, thông thường bạn có tạo một quyền không?

Xin lỗi, tôi không hiểu hết câu hỏi nên tôi sẽ nói rộng hơn một chút. Để cấp / từ chối quyền truy cập vào a resource, bạn cần:

  • Xác định các chính sách của bạn
  • Xác định quyền của bạn
  • Áp dụng các chính sách của bạn cho các quyền của bạn
  • Liên kết các quyền của bạn với một scopehoặc resource(hoặc cả hai)

để việc thực thi chính sách có hiệu lực. Xem Quy trình cấp phép .

Cách bạn thiết lập tất cả những điều này là hoàn toàn tùy thuộc vào bạn. Ví dụ, bạn có thể:

  • Xác định các chính sách riêng lẻ và ràng buộc từng chính sách dưới sự cho phép thích hợp.

  • Tốt hơn, hãy xác định các chính sách riêng lẻ, sau đó nhóm tất cả các chính sách có liên quan của bạn theo một aggregatedchính sách (một chính sách của các chính sách) và sau đó kết hợp chính sách tổng hợp đó với sự scope-basedcho phép. Bạn có thể có scoped-basedquyền đó áp dụng cho cả tài nguyên và tất cả phạm vi liên quan của nó.

  • Hoặc, bạn có thể chia nhỏ các quyền của mình hơn nữa bằng cách tận dụng hai loại riêng biệt. Bạn chỉ có thể tạo các quyền cho tài nguyên của mình thông qua resource-basedloại quyền và liên kết riêng các quyền khác chỉ với một phạm vi thông qua scope-basedloại quyền.

Bạn có các tùy chọn.

Nếu có nhiều quyền phù hợp với một tài nguyên / phạm vi nhất định, Keycloak sẽ làm gì?

Điều này phụ thuộc vào

  1. Máy chủ tài nguyên của Decision Strategy
  2. Mỗi quyền của Decision Strategy
  3. LogicGiá trị của từng chính sách .

Các Logicgiá trị cũng tương tự như với Java của !nhà điều hành. Nó có thể là Positivehoặc Negative. Khi Logiclà Positive, đánh giá cuối cùng của chính sách vẫn không thay đổi. Khi mình Negative, kết quả cuối cùng là phủ nhận (ví dụ nếu một đánh giá lại chính sách sai lầm và nó Logiclà Negative, sau đó nó sẽ được true). Để giữ mọi thứ đơn giản, hãy giả sử rằng Logicluôn được đặt thành Positive.

Các Decision Strategylà những gì chúng ta thực sự muốn giải quyết. Có Decision Strategythể là Unanimoushoặc Affirmative. Từ các tài liệu,

Chiến lược quyết định

Cấu hình này thay đổi cách công cụ đánh giá chính sách quyết định có nên cấp tài nguyên hoặc phạm vi hay không dựa trên kết quả từ tất cả các quyền được đánh giá. Khẳng định có nghĩa là ít nhất một quyền phải đánh giá một quyết định tích cực để cấp quyền truy cập vào tài nguyên và phạm vi của nó. Nhất trí có nghĩa là tất cả các quyền phải đánh giá đến một quyết định tích cực để quyết định cuối cùng cũng tích cực. Ví dụ: nếu hai quyền cho cùng một tài nguyên hoặc phạm vi xung đột (một trong hai quyền đang cấp quyền truy cập và quyền kia từ chối quyền truy cập), quyền đối với tài nguyên hoặc phạm vi sẽ được cấp nếu chiến lược đã chọn là Khẳng định. Nếu không, một lần từ chối bất kỳ quyền nào cũng sẽ từ chối quyền truy cập vào tài nguyên hoặc phạm vi.

Hãy sử dụng một ví dụ để hiểu rõ hơn ở trên. Giả sử bạn có một tài nguyên với 2 quyền và ai đó đang cố gắng truy cập vào tài nguyên đó (hãy nhớ, đó Logiclà quyền Positivecho tất cả các chính sách). Hiện nay:

  1. Permission Onecó một Decision Strategybộ để Affirmative. Nó cũng có 3 chính sách mà mỗi chính sách đánh giá:
    • true
    • false
    • false

Vì một trong các chính sách được đặt thành true, Permission Oneđược đặt thành true(Khẳng định - chỉ cần 1 true).

  1. Permission Twocó một Decision Strategybộ Unanimousvới 2 chính sách:
    • true
    • false

Trong trường hợp Permission Twonày là falsevì một chính sách là sai (Nhất trí - tất cả đều cần phải như vậy true).

  1. Bây giờ đến đánh giá cuối cùng . Nếu máy chủ tài nguyên của Decision Strategyđược đặt thành Affirmative, quyền truy cập vào tài nguyên đó sẽ được cấp vì Permission Onelà như vậy true. Mặt khác, nếu máy chủ tài nguyên Decision Strategyđược đặt thành Unanimous, quyền truy cập sẽ bị từ chối.

Xem:

Chúng tôi sẽ tiếp tục xem lại điều này. Tôi giải thích cách đặt máy chủ tài nguyên Decision Strategy trong Phần II.

vì vậy, ví dụ: tôi có thể có quyền truy cập vào "tài khoản" và quyền đối với phạm vi "xem", vì vậy tôi sẽ có quyền xem tài khoản?

Câu trả lời ngắn gọn là có. Bây giờ, hãy mở rộng vấn đề này một chút :)

Nếu bạn gặp trường hợp sau:

  1. Máy chủ tài nguyên Decision Strategyđược đặt thành UnanimoushoặcAffirmative
  2. Quyền truy cập account/{id}tài nguyên làtrue
  3. Quyền truy cập viewphạm vi làtrue

Bạn sẽ được cấp quyền truy cập để xem tài khoản.

  • true+ truebằng với truedưới dấu Affirmativehoặc Unanimous Decision Strategy.

Bây giờ nếu bạn có cái này

  1. Máy chủ tài nguyên Decision Strategyđược đặt thànhAffirmative
  2. Quyền truy cập account/{id}tài nguyên làtrue
  3. Quyền truy cập viewphạm vi làfalse

Bạn cũng sẽ được cấp quyền truy cập để xem tài khoản.

  • true+ falseLà truedưới Affirmativechiến lược.

Vấn đề ở đây là quyền truy cập vào một tài nguyên nhất định cũng phụ thuộc vào thiết lập của bạn, vì vậy hãy cẩn thận vì bạn có thể không muốn gặp trường hợp thứ hai.

Nhưng tôi nói đúng rằng điều này có nghĩa là tôi cần một chính sách cho từng nhóm kế thừa mà người dùng có thể thuộc về?

Tôi không chắc Keycloak đã hoạt động như thế nào cách đây 2 năm, nhưng bạn có thể chỉ định chính sách Dựa trên nhóm và chỉ cần thêm tất cả các nhóm của bạn theo chính sách đó. Bạn chắc chắn không cần tạo một chính sách cho mỗi nhóm.

Ví dụ: nếu tôi có vai trò "bộ phận trợ giúp", thì tôi cần chính sách "tư cách thành viên bộ phận trợ giúp", sau đó tôi có thể thêm chính sách này vào quyền "viewAccount". Điều này có chính xác?

Khá nhiều. Có nhiều cách bạn có thể thiết lập điều này. Ví dụ, bạn có thể:

  1. Tạo tài nguyên của bạn (ví dụ /account/{id}) và liên kết nó với account:viewphạm vi.
  2. tạo Chính sách dựa trênhelpdesk vai trò và thêm vai trò theo chính sách đó
  3. Tạo một Scope-Basedquyền được gọi viewAccountvà gắn nó với scope, resourcevàpolicy

Chúng tôi sẽ thiết lập một cái gì đó tương tự trong Phần II.

Phần II

Keycloak có một công cụ nhỏ gọn gàng cho phép bạn kiểm tra tất cả các chính sách của mình. Tốt hơn nữa, bạn thực sự không cần phải khởi động một máy chủ ứng dụng khác và triển khai một ứng dụng riêng để nó hoạt động.

Đây là kịch bản mà chúng tôi sẽ thiết lập:

  1. Chúng tôi sẽ tạo ra một lĩnh vực mới được gọi là stackoverflow-demo
  2. Chúng tôi sẽ tạo một bank-apikhách hàng trong lĩnh vực đó
  3. Chúng tôi sẽ xác định một tài nguyên được gọi /account/{id}cho khách hàng đó
  4. Ý account/{id}chí có account:viewphạm vi
  5. Chúng tôi sẽ tạo một người dùng được gọi bobtrong lĩnh vực mới
  6. Chúng tôi cũng sẽ tạo ra ba vai trò: bank_teller, account_ownervàuser
    • Chúng tôi sẽ không liên kết bobvới bất kỳ vai trò nào. Điều này là không cần thiết ngay bây giờ.
  7. Chúng tôi sẽ thiết lập hai Role-Basedchính sách sau:
    • bank_tellervà account_ownercó quyền truy cập vào /account/{id}tài nguyên
    • account_ownercó quyền truy cập vào account:viewphạm vi
    • user không có quyền truy cập vào tài nguyên hoặc phạm vi
  8. Chúng tôi sẽ thử với Evaluatecông cụ này để xem cách cấp hoặc từ chối quyền truy cập.

Hãy tha thứ cho tôi, ví dụ này là không thực tế nhưng tôi không quen thuộc với lĩnh vực ngân hàng :)

Thiết lập móc khóa

Tải xuống và chạy Keycloak

cd tmp
wget https://downloads.jboss.org/keycloak/8.0.0/keycloak-8.0.0.zip 
unzip keycloak-8.0.0.zip
cd keycloak-8.0.0/bin
./standalone.sh

Tạo người dùng quản trị ban đầu

  1. Đi đến http://localhost:8080/auth
  2. Bấm vào Administration Console liên kết
  3. Tạo người dùng quản trị và đăng nhập

Truy cập Bắt đầu để biết thêm thông tin. Đối với mục đích của chúng tôi, những điều trên là đủ.

Thiết lập sân khấu

Tạo một lĩnh vực mới

  1. Di chuột xung quanh mastervương quốc và nhấp vàoAdd Realm nút.
  2. Đi vào stackoverflow-demo như tên.
  3. Bấm vào Create .
  4. Trên cùng bên trái bây giờ nên nói stackoverflow-demothay vì mastercảnh giới.

Xem Tạo một Vương quốc Mới

Tạo người dùng mới

  1. Nhấp vào Usersliên kết bên trái
  2. Bấm vào Add Usernút
  3. Nhập username(ví dụ bob)
  4. Đảm bảo rằng User Enabledđã bật
  5. Nhấp chuột Save

Xem Tạo người dùng mới

Tạo vai trò mới

  1. Bấm vào Rolesliên kết
  2. Bấm vào Add Role
  3. Thêm các vai trò sau: bank_teller, account_ownervàuser

Một lần nữa, không liên kết người dùng của bạn với các vai trò. Đối với mục đích của chúng tôi, điều này là không cần thiết.

Xem vai trò

Tạo khách hàng

  1. Bấm vào Clientsliên kết
  2. Bấm vào Create
  3. Nhập bank-apichoClient ID
  4. Để Root URLnhậphttp://127.0.0.1:8080/bank-api
  5. Bấm vào Save
  6. Đảm bảo rằng Client Protocollàopenid-connect
  7. Thay đổi Access Typethànhconfidential
  8. Thay đổi Authorization EnabledthànhOn
  9. Cuộn xuống và nhấn Save. Một mớiAuthorization tab sẽ xuất hiện ở trên cùng.
  10. Nhấp vào Authorizationtab và sau đóSettings
  11. Đảm bảo rằng Decision Strategythiết lập được đặt thànhUnanimous
    • Đây là máy chủ tài nguyên của Decision Strategy

Xem:

Tạo phạm vi tùy chỉnh

  1. Bấm vào Authorizationtab
  2. Bấm vào Authorization Scopes> Createđể hiển thị Add Scopetrang
  3. Nhập account:viewtên và nhấn Enter.

Tạo "Xem tài nguyên tài khoản"

  1. Bấm vào Authorizationliên kết trên
  2. Bấm vào Resources
  3. Bấm vào Create
  4. Nhập View Account Resourcecho cả NamevàDisplay name
  5. Nhập account/{id}choURI
  6. Nhập account:viewvào Scopeshộp văn bản
  7. Nhấp chuột Save

Xem Tạo tài nguyên

Tạo chính sách của bạn

  1. Một lần nữa trong Authorizationtab, nhấp vàoPolicies
  2. Chọn RoletừCreate Policy menu thả xuống
  3. Trong Namephần này, hãy nhậpOnly Bank Teller and Account Owner Policy
  4. Dưới Realm Roleschọn cả vai trò bank_tellervàaccount_owner
  5. Đảm bảo rằng Logicđược đặt thànhPositive
  6. Nhấp chuột Save
  7. Bấm vàoPolicies liên kết
  8. Chọn Rolelại từ Create Policymenu thả xuống.
  9. Thời gian này sử dụng Only Account Owner PolicychoName
  10. Dưới Realm Roleslựa chọnaccount_owner
  11. Đảm bảo rằng Logicđược đặt thànhPositive
  12. Nhấp chuột Save
  13. Nhấp vào Policiesliên kết ở trên cùng, bây giờ bạn sẽ thấy các chính sách mới được tạo của mình.

Xem Chính sách dựa trên vai trò

Xin lưu ý rằng Keycloak có nhiều chính sách mạnh mẽ hơn. Xem Chính sách Quản lý

Tạo quyền dựa trên tài nguyên

  1. Một lần nữa trong Authorizationtab, nhấp vàoPermissions
  2. Lựa chọn Resource-Based
  3. Nhập View Account Resource PermissionchoName
  4. Dưới ResourcesloạiView Account Resource Permission
  5. Dưới Apply Policylựa chọnOnly Bank Teller and Account Owner Policy
  6. Đảm bảo rằng Decision Strategythiết lập được đặt thànhUnanimous
  7. Nhấp chuột Save

Xem Tạo quyền dựa trên tài nguyên

Phù ...

Đánh giá quyền dựa trên tài nguyên

  1. Một lần nữa trong Authorizationtab, hãy chọnEvaluate
  2. Dưới Usernhậpbob
  3. Dưới Roleslựa chọnuser
    • Đây là nơi chúng tôi sẽ liên kết người dùng của mình với các vai trò đã tạo của chúng tôi.
  4. Dưới Resourceschọn View Account Resourcevà nhấpAdd
  5. Nhấp vào Đánh giá.
  6. Mở rộng View Account Resource with scopes [account:view]để xem kết quả và bạn sẽ thấy DENY.

nhập mô tả hình ảnh ở đây

  1. Điều này có ý nghĩa vì chúng tôi chỉ cho phép hai vai trò truy cập vào tài nguyên đó thông qua Only Bank Teller and Account Owner Policy. Hãy kiểm tra điều này để đảm bảo điều này là đúng!
  2. Nhấp vào Backliên kết ngay trên kết quả đánh giá
  3. Thay đổi vai trò của bob thành account_ownervà nhấp vào Evaluate. Bây giờ bạn sẽ thấy kết quả là PERMIT. Thỏa thuận tương tự nếu bạn quay lại và thay đổi vai trò thànhbank_teller

Xem Chính sách Đánh giá và Kiểm tra

Tạo quyền dựa trên phạm vi

  1. Quay lại Permissionsphần
  2. Chọn Scope-Basedthời gian này trong Create Permissionmenu thả xuống.
  3. Dưới Name, nhậpView Account Scope Permission
  4. Dưới Scopes, nhậpaccount:view
  5. Dưới Apply Policy, nhậpOnly Account Owner Policy
  6. Đảm bảo rằng Decision Strategythiết lập được đặt thànhUnanimous
  7. Nhấp chuột Save

Xem Tạo quyền dựa trên phạm vi

Lần chạy thử thứ hai

Đánh giá những thay đổi mới của chúng tôi

  1. Quay lại Authorizationphần
  2. Bấm vào Evaluate
  3. Người dùng nên bob
  4. Vai trò nên được bank_teller
  5. Tài nguyên nên được View Account Resourcevà nhấp vàoAdd
  6. Nhấp vào Evaluatevà chúng ta sẽ nhận được DENY.
    • Một lần nữa, điều này sẽ không có gì ngạc nhiên khi bank_tellercó quyền truy cập vào resourcenhưng không phải scope. Ở đây một quyền đánh giá là true và quyền kia là false. Cho rằng máy chủ tài nguyên Decision Strategyđược đặt thành Unanimous, quyết định cuối cùng là DENY.
  7. Nhấp vào Settingsbên dưới Authorizationtab và thay đổi Decision Strategythành Affirmativevà quay lại các bước 1-6 một lần nữa. Lần này, kết quả cuối cùng sẽ là PERMIT(một sự cho phép là đúng, vì vậy quyết định cuối cùng là đúng).
  8. Để hoàn thiện, hãy chuyển máy chủ tài nguyên Decision Strategytrở lại Unanimous. Một lần nữa, quay lại các bước từ 1 đến 6 nhưng lần này, đặt vai trò là account_owner. Lần này, kết quả cuối cùng một lần nữa PERMITcó ý nghĩa, vì nó account_ownercó quyền truy cập vào cả resourcevà scope.

Gọn gàng :) Hy vọng điều này sẽ giúp.

— Andy
nguồn
1
@SANDEEPMACHIRAJU Bạn được chào đón :) Câu hỏi hay! Không đủ ký tự để đưa ra câu trả lời chuyên sâu thông qua nhận xét nhưng bạn có thể sử dụng điểm cuối nội quan mã thông báo . Đây là danh sách tất cả các điểm cuối của họ . Tôi nghĩ bạn cũng có thể sử dụng Ứng dụng khách ủy quyền của họ nhưng tôi không có bất kỳ kinh nghiệm nào về việc sử dụng nó
— Andy
7
Cảm ơn vì câu trả lời tuyệt vời.
— Markus
3
@JWo Bạn được chào đón! Tbh, không có lý do cụ thể. Tôi chỉ giữ ví dụ đơn giản nhất có thể để mọi người bắt đầu. Tôi biết từ kinh nghiệm rằng tài liệu không phải là thứ thú vị nhất để đọc. Đối với một khách hàng khác cần quyền truy cập vào API ngân hàng, có vẻ như bạn đang tìm kiếm User Management Access (UMA)nơi chủ sở hữu tài nguyên có thể cấp quyền truy cập vào tài nguyên được bảo vệ cho bên yêu cầu (ít nhất đó là cách hiểu của tôi).
— Andy
3
Bạn chắc chắn đang làm cho thế giới trở thành một nơi tốt đẹp hơn nhờ dành thời gian để tập hợp tất cả những điều đó lại với nhau ... Bạn nên viết một số bài đăng trên blog về tất cả những điều này! Rất hữu ích @Andy
— José Carlos
1
@Andy chỉ wow! Cảm ơn bạn đã dành thời gian đọc tất cả tài liệu Dịch vụ xác thực và chia sẻ tài liệu đó với chúng tôi. Bạn đã tiết kiệm cho nhiều người rất nhiều giờ học tập! Chỉ có một điều tôi không thể thấy. Bạn đã nói account_owner has access to the account:view scope. Làm thế nào để bạn củng cố mối quan hệ giữa vai trò đó và phạm vi đó?
— codependent
5

Tôi đang tìm cách thực thi ủy quyền thông qua các phương thức HTTP thuần túy mà không sử dụng bộ điều hợp vì Lua không có bộ điều hợp. Hy vọng câu trả lời này sẽ giúp những người đang tìm kiếm phương pháp dựa trên bộ điều hợp không.

Nếu bạn đang tìm kiếm bộ chuyển đổi, hướng dẫn bắt đầu nhanh là nơi tốt nhất để bắt đầu. Đặc biệt là ví dụ authz khởi động mùa xuân .

Đối với triển khai dựa trên HTTP thuần túy:

Bước 1:

Xác định các chính sách và quyền trong Giao diện người dùng quản trị Keycloak

Bước 2

Có ánh xạ nội bộ về đường dẫn HTTP nào thuộc về tài nguyên nào và phạm vi bắt buộc cho mỗi đường dẫn. Điều này cũng có thể được lưu trong tệp cấu hình . Khi một tuyến đường cụ thể được gọi, hãy gọi điểm cuối mã thông báo Keycloak để xác thực các yêu cầu của mã thông báo truy cập.

{
  "policy-enforcer": {
    "user-managed-access" : {},
    "enforcement-mode" : "ENFORCING"
    "paths": [
      {
        "path" : "/someUri/*",
        "methods" : [
          {
            "method": "GET",
            "scopes" : ["urn:app.com:scopes:view"]
          },
          {
            "method": "POST",
            "scopes" : ["urn:app.com:scopes:create"]
          }
        ]
      }
    ]
  }
}

Nếu bạn đang sử dụng bộ điều hợp và không chỉ định đường dẫn hoặc tài nguyên, bộ điều hợp sẽ tìm kiếm nội bộ đường dẫn và tài nguyên từ Keycloak .

Bước 3:

Sử dụng điểm cuối mã thông báo để nhận hoặc đánh giá các quyền. Bạn có thể sử dụng response_modetham số để có được quyết định cuối cùng (có cung cấp quyền truy cập hay không) hoặc truy xuất toàn bộ quyền.

curl -X POST \
  http://${host}:${port}/auth/realms/${realm}/protocol/openid-connect/token \
  -H "Authorization: Bearer ${access_token}" \
  --data "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket" \
  --data "permission=Resource A#Scope A"

Nếu yêu cầu ủy quyền không liên quan đến bất kỳ quyền nào, 403thay vào đó, mã trạng thái HTTP sẽ được trả về.

— Nirojan Selvanathan
nguồn
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.