Bạn đang xem tài liệu về Apigee Edge.
Chuyển đến
Tài liệu về Apigee X. thông tin
Trong chủ đề này, chúng ta sẽ thảo luận về cách nhập mã truy cập được tạo bên ngoài, mã làm mới, hoặc mã xác thực vào cửa hàng mã thông báo Edge. Bạn có thể sử dụng kỹ thuật này nếu muốn định cấu hình Apigee Edge để xác thực mã thông báo được tạo bên ngoài Apigee Edge.
Trong trường hợp thông thường, Apigee Edge sẽ tạo và lưu trữ một mã thông báo OAuth rồi trả lại mã đó cho ứng dụng gọi điện. Sau đó, ứng dụng gọi sẽ hiển thị mã thông báo đó trở lại với Apigee Edge khi yêu cầu và Apigee Edge (thông qua chính sách OAuthV2) có Operation = VerifyAccessToken – sẽ xác minh rằng mã thông báo là hợp lệ. Chủ đề này mô tả cách bạn có thể định cấu hình Apigee Edge để lưu trữ mã thông báo OAuth được tạo ở nơi khác, trong khi vẫn giữ nguyên phần xác minh mã thông báo, giống như mã thông báo đó do Edge tạo.
Ví dụ:
Nếu bạn muốn xem ví dụ minh hoạ cho kỹ thuật được mô tả trong chủ đề này, hãy xem hàm Apigee Mẫu Quản lý mã thông báo được uỷ quyền.
Đây là gì?
Giả sử bạn đã có sẵn hệ thống uỷ quyền và bạn muốn sử dụng mã thông báo hoặc giá trị mã do hệ thống đó tạo ra thay cho mã thông báo OAuth2 hoặc giá trị mã Edge sẽ được tạo. Sau đó, bạn có thể thực hiện các yêu cầu proxy API bảo mật bằng mã thông báo hoặc mã được thay thế, và Edge sẽ xác thực chúng như thể chúng do Edge tạo.
Một số thông tin cơ bản
Trong trường hợp thông thường, Apigee Edge sẽ tạo một mã thông báo bằng cách tạo một chuỗi chữ cái ngẫu nhiên và số. Apigee Edge liên kết với mã thông báo đó và các dữ liệu khác như thời điểm phát hành mã thông báo, ngày hết hạn, danh sách các sản phẩm API có mã thông báo hợp lệ và phạm vi. Toàn bộ thông tin có thể được trả về trong một phản hồi do chính sách OAuthV2 tạo tự động được định cấu hình bằng Operation = GenerateAccessToken. Phản hồi sẽ có dạng như sau:
{
"issued_at": "1469735625687",
"application_name": "06947a86-919e-4ca3-ac72-036723b18231",
"scope": "urn://example.com/read",
"status": "approved",
"api_product_list": "[implicit-test]",
"api_product_list_json": ["implicit-test"],
"expires_in": "1799", //--in seconds
"developer.email": "joe@weathersample.com",
"token_type": "BearerToken",
"client_id": "U9AC66e9YFyI1yqaXgUF8H6b9wUN1TLk",
"access_token": "zBC90HhCGmGlaMBWeZAai2s3za5j",
"organization_name": "wwitman",
"refresh_token_expires_in": "0", //--in seconds
"refresh_count": "0"
}
Giá trị của thuộc tính access_token là khoá tra cứu thực tế cho
dữ liệu phản hồi. Ứng dụng có thể gửi yêu cầu đến một proxy API được lưu trữ trong Edge,
mang mã thông báo truyền tải zBC90HhCGmGlaMBWeZAai2s3za5j và Edge – bằng OAuthV2
chính sách với Operation = VerifyAccessToken – sẽ tra cứu mã thông báo, truy xuất tất cả thông tin,
và dùng thông tin đó để xác định xem mã thông báo có hợp lệ hay không, cho Proxy API được yêu cầu.
Quá trình này được gọi là Xác thực mã thông báo. Tất cả thông tin trên đều bao gồm mã thông báo. Chiến lược phát hành đĩa đơn
giá trị access_token chỉ là cách tra cứu thông tin đó.
Mặt khác, bằng cách làm theo các bước được mô tả ở đây, bạn có thể định cấu hình Edge để lưu trữ mã thông báo để giá trị access_token của mã là giá trị được tạo bởi . Tất cả các siêu dữ liệu khác có thể giống nhau. Ví dụ: giả sử bạn có một hệ thống bên ngoài Apigee Edge tạo mã thông báo có dạng "TOKEN-<16 ngẫu nhiên" số>" của Google. Trong trường hợp đó, toàn bộ siêu dữ liệu mã thông báo mà Apigee Edge lưu trữ có thể sẽ:
{
"issued_at": "1469735625687",
"application_name": "06947a86-919e-4ca3-ac72-036723b18231",
"scope": "urn://example.com/read",
"status": "approved",
"api_product_list": "[implicit-test]",
"api_product_list_json": ["implicit-test"],
"expires_in": "1799", //--in seconds
"developer.email": "joe@weathersample.com",
"token_type": "BearerToken",
"client_id": "U9AC66e9YFyI1yqaXgUF8H6b9wUN1TLk",
"access_token": "TOKEN-1092837373654221",
"organization_name": "wwitman",
"refresh_token_expires_in": "0", //--in seconds
"refresh_count": "0"
}
Trong trường hợp này, ứng dụng có thể gửi yêu cầu đến một proxy API được lưu trữ trong Edge, mang theo hàm mang
mã thông báo TOKEN-1092837373654221 và Edge – thông qua chính sách OAuthV2 với Thao tác =
VerifyAccessToken – sẽ có thể xác thực mã này. Bạn có thể áp dụng mẫu nhập tương tự cho
mã uỷ quyền và mã làm mới.
Hãy cùng tìm hiểu về việc xác thực ứng dụng Thông tin xác thực
Một điều kiện tiên quyết để tạo mã thông báo là xác thực ứng dụng yêu cầu. Theo mặc định, Chính sách OAuthV2/GenerateAccessToken trong Apigee Edge sẽ ngầm xác minh thông tin đăng nhập của ứng dụng. Thông thường, trong một yêu cầu mã thông báo OAuthV2, client_id và client_secret được chuyển vào Tiêu đề uỷ quyền, được mã hoá qua Yêu cầu uỷ quyền cơ bản HTTP (được nối với dấu hai chấm, sau đó là được mã hoá base64). Chính sách OAuthV2/GenerateAccessToken trong Apigee Edge sẽ giải mã tiêu đề đó và tra cứu client_id và xác minh rằng client_secret được gửi là hợp lệ client_id. Phương thức này sẽ hoạt động nếu thông tin đăng nhập mà Apigee Edge biết đến, tức là có Ứng dụng của nhà phát triển được lưu trữ trong Apigee Edge có chứa thông tin đăng nhập, bản thân ứng dụng này chứa client_id và client_secret cung cấp.
Trong trường hợp Apigee Edge không xác thực thông tin đăng nhập của ứng dụng khách, bạn phải thiết kế Proxy API của mình trước khi tạo mã thông báo để xác thực rõ ràng ứng dụng khách thông qua một số phương tiện khác. Thông thường, điều này là thông qua chính sách Dịch vụ chú thích kết nối với một điểm cuối từ xa trong mạng của bạn.
Dù bằng cách này hay cách khác, dù ngầm ẩn hoặc rõ ràng, bạn cần đảm bảo rằng Proxy API để tạo mã thông báo. Trước tiên, hãy xác thực thông tin đăng nhập của ứng dụng khách. Xin lưu ý rằng việc xác thực không phụ thuộc vào việc tạo mã truy cập. Bạn có thể định cấu hình Apigee Edge để làm cả hai việc này, hoặc làm một trong hai việc này hoặc không làm gì cả.
Nếu bạn muốn chính sách OAuthV2/GenerateAccessToken trong Apigee Edge để xác thực ứng dụng
thông tin xác thực vào Cửa hàng Edge, hãy đặt phần tử <ExternalAuthorization> thành
false bên trong cấu hình chính sách hoặc bỏ qua hoàn toàn. Nếu bạn muốn sử dụng một
dịch vụ uỷ quyền bên ngoài để xác thực rõ ràng thông tin đăng nhập ứng dụng, đặt
<ExternalAuthorization> thành true.
Mặc dù Apigee Edge có thể không xác thực thông tin đăng nhập của khách hàng, nhưng điều này vẫn cần thiết cho client_id được Apigee Edge quản lý và biết đến. Mọi access_token trong Apigee Edge, cho dù do Apigee Edge tạo hoặc do một hệ thống bên ngoài tạo ra, sau đó được nhập vào Apigee Edge, phải được liên kết với ứng dụng khách – được biểu thị bằng client_id. Kể cả trong trường hợp trong đó chính sách OAuthV2/GenerateAccessToken trong Apigee Edge sẽ không xác thực rằng client_id và client_secret phù hợp, chính sách sẽ xác thực rằng client_id hợp lệ, có tồn tại và không bị thu hồi. Vì vậy, trong bước thiết lập tiên quyết, bạn có thể phải nhập client_id's qua Edge quản trị.
Quy trình chính sách cho OAuth của bên thứ ba trên Apigee
Để dùng mã thông báo từ hệ thống OAuth của bên thứ ba trong Apigee Edge, quy trình tạo quyền truy cập mã thông báo phải tuân theo một trong các mẫu sau.
Ngoài Xác thực thông tin đăng nhập của khách hàng
- ServiceCallout để xác minh thông tin xác thực ứng dụng đến và lấy mã thông báo bên ngoài.
- ExtractVariables hoặc một Bước JavaScript để trích xuất mã thông báo được tạo bên ngoài từ phản hồi.
- AssignMessage cho
đặt biến phổ biến đặc biệt có tên là
oauth_external_authorization_status. Giá trị này phải đúng để cho biết thông tin đăng nhập của ứng dụng khách là hợp lệ. - OAuthV2/GenerateAccessToken bằng
Đã đặt phần tử
<ExternalAuthorization>thànhtruevà có ít nhất một phần tử trong tổng số<ExternalAccessToken>,<ExternalRefreshToken>hoặc<ExternalAuthorizationCode>.
Nội bộ Xác thực thông tin đăng nhập của khách hàng
- ServiceCallout để có được mã thông báo bên ngoài.
- ExtractVariables hoặc một Bước JavaScript để trích xuất mã thông báo được tạo bên ngoài từ phản hồi.
- OAuthV2/GenerateAccessToken bằng
Đã đặt phần tử
<ExternalAuthorization>thànhfalsevà có ít nhất một phần tử trong tổng số<ExternalAccessToken>,<ExternalRefreshToken>hoặc<ExternalAuthorizationCode>.
Lưu ý về cấu hình quy trình và chính sách
-
Trong trường hợp bạn muốn sử dụng hệ thống bên ngoài để xác thực thông tin đăng nhập của ứng dụng, thì bạn có thể xây dựng một quy trình chính sách thực hiện những việc cần thiết. Thông thường, bạn nên sử dụng Chính sách về chú thích dịch vụ để gửi thông tin xác thực được công nhận bên ngoài tới ứng dụng bên ngoài dịch vụ xác thực. Dịch vụ xác thực bên ngoài thường sẽ trả về một phản hồi và nếu thông tin xác thực hợp lệ thì cũng là mã truy cập.
-
Sau ServiceAnnotation, proxy API cần phân tích cú pháp phản hồi để trích xuất trạng thái hợp lệ, cũng như access_token được tạo bên ngoài và có thể là refresh_token.
-
Trong chính sách OAuthV2/GenerateAccessToken, hãy đặt phần tử
<StoreToken>thànhtruevà đặt phần tử<ExternalAuthorization>thànhtruehoặcfalsenếu phù hợp.Khi thực thi chính sách OAuthV2/GenerateAccessToken, chính sách này sẽ đọc biến
oauth_external_authorization_status. Nếu biến được đặt và giá trị là true thì Apigee Edge sẽ không tìm cách xác thực thông tin đăng nhập của ứng dụng. Nếu biến nếu bạn đặt chính sách này thành không đặt hoặc giá trị không đúng, thì Apigee Edge sẽ tìm cách xác thực ứng dụng thông tin xác thực. -
Có 3 phần tử của chính sách OAuthV2 cho phép bạn chỉ định dữ liệu cần nhập:
<ExternalAccessToken>,<ExternalRefreshToken>, và<ExternalAuthorizationCode>. Mỗi phần tử trong số này chấp nhận biến luồng. Chính sách Edge sẽ đọc biến đó để tìm mã truy cập do bên ngoài tạo, mã làm mới hoặc mã uỷ quyền. Điều này tuỳ thuộc vào bạn triển khai các chính sách và logic để đặt các mã thông báo hoặc mã bên ngoài vào vị trí thích hợp biến.Ví dụ: cấu hình sau đây trong chính sách OAuthV2 yêu cầu Edge tìm mã thông báo trong biến ngữ cảnh có tên
external_token.<ExternalAccessToken>external_token</ExternalAccessToken>
Bạn cũng cần có bước trước để đặt biến đó.
-
Đối với việc đặt biến
oauth_external_authorization_status, một phổ biến kỹ thuật để đặt biến này là sử dụng chính sách AssignmentMessage với phần tử AttributionVariable như sau:<AssignMessage name="AssignMessage-SetVariable"> <DisplayName>Assign Message - Set Variable</DisplayName> <AssignVariable> <Name>oauth_external_authorization_status</Name> <Value>true</Value> </AssignVariable> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> </AssignMessage>Xin lưu ý rằng chính sách này phải trước chính sách OAuthV2 với toán tử Operation = GenerateAccessToken.
Ví dụ về chính sách OAuthV2
Chính sách OAuthV2 sau đây
tạo mã truy cập Apigee Edge vì Edge tìm thấy
giá trị mã thông báo trong biến luồng external_access_token.
<OAuthV2 name="OAuth-v20-Store-External-Token">
<ExternalAccessToken>external_access_token</ExternalAccessToken>
<ExternalAuthorization>true</ExternalAuthorization>
<Operation>GenerateAccessToken</Operation>
<GenerateResponse enabled="true">
<Format>FORM_PARAM</Format>
</GenerateResponse>
<ReuseRefreshToken>false</ReuseRefreshToken>
<StoreToken>true</StoreToken>
<SupportedGrantTypes>
<GrantType>client_credentials</GrantType>
</SupportedGrantTypes>
<ExpiresIn ref='flow.variable'>2400000</ExpiresIn>
</OAuthV2>
Về lý thuyết, bạn có thể áp dụng mẫu này với bất kỳ hoạt động uỷ quyền OAuth2 nào của bên thứ ba .