Copyright © 2013 Open Geospatial Consortium
9
5.5.1 GEOAxIS PEP and PDP
Figure 6 — Flow of communication for GEOAxIS PEP and PDP
1. The User submits a WFS request via the ESRI Visualization Application 2. The Proxy intercepts the request and forwards it to the Oracle Access Manager
OAM. 3. OAM checks if resource is protected and whether an ObSSOCookie exists. In this
use case, the resource is protected and there is no ObSSOCookie on the request. As the result, an HTTP 302 redirect response is returned.
4. Proxy forwards HTTP 302 response to the Visualization Application 5. Authentication ATN request is generated.
6. Proxy intercepts ATN request and forwards it to the OAM Credential Collector CC
7. User credentials uidpwd must be validated, thus OAM CC forwards the request to the Policy Information Point PIP.
8. PIP returns credential successful validation. 9. OAM CC generates a session token with a URL that contains the
ObSSOCookie. User is athenticated and ObSSOCookie is forwarded to the Proxy.
Copyright © 2013 Open Geospatial Consortium
10 10. Proxy forwards HTTP 302 + authenticated response
11. Proxy appends the userid into the WFS header and forwards to the Policy Enforcement Point PEP.
12. PEP sends information to the Policy Decision Point PDP to determine if user request is permitted to be sent to the WFS endpoint.
13. PDP makes decision and returns response to PEP. 14. Upon receipt of a successful response from the PDP, the PEP routes the WFS
request to the WFS service endpoint 15. – 17. WFS endpoint response is routed to requester end user.
5.5.2 GEOAxIS PEP and Secure Dimensions PDP
Figure 7 — Flow of communication for GEOAxIS PEP and Secure Dimensions PDP
The flow of communication is identical to 5.2.1. even though another participant provides the PDP.
Copyright © 2013 Open Geospatial Consortium
11
5.5.3 GEOAxIS PEP and con terra PDP
Figure 8 — Flow of communication for GEOAxIS PEP and con terra PDP
The flow of communication is identical to 5.2.1. even though another participant provides the PDP.
5.5.4 con terra PEP con terra PDP
Copyright © 2013 Open Geospatial Consortium
12
Figure 9 — Flow of communication for con terra PEP and PDP
1. User submits a WFS request via the Visualization Application. 2. Proxy intercepts request and forwards it to Oracle Access Manager OAM.
3. OAM checks if resource is protected and whether an ObSSOCookie exists. In this
use case, the resource is protected and there is no ObSSOCookie on the request, as a result, an HTTP 302 redirect response is forwarded to the browser.
4. Proxy forwards HTTP 302 response to the browser. 5. Authentication request is generated.
6. Proxy intercepts ATN request and forwards to the OAM Credential Collector
CC. 7. User credentials uidpwd must be validated, thus OAM CC forwards the
request to the Policy Information Point PIP. 8. PIP returns successful credential validation.
9. OAM Credential Collector generates a session token with a URL that contains the ObSSOCookie. User is athenticated and ObSSOCookie is forwarded to
ProxyWebGate. 10. Proxy forwards HTTP 302 + authenticated response.
11. OAM WebGate appends the userid into the WFS header and forwards to the Policy Enforcement Point PEP.
12. WFS SOAP is routed to con terra PEP. 13. PEP sends information to the Policy Decision Point PDP to determine if user
request is permitted to be sent to the WFS Service Endpoint. 14. PDP makes decision and returns response to PEP.
15. Upon receipt of a successful response from the PDP, the PEP routes the WFS request to the WFS endpoint.
16. – 18. WFS endpoint returns the response to the end user.
Copyright © 2013 Open Geospatial Consortium
13
5.5.5 con terra PEP and Secure Dimensions PDP
Kategori