OAM 11g Webgate flow:
1. An OAM 11g Webgate intercepts the incoming request for a resource, determines whether the resource is protected.
a. If it is Unprotected : User will able to see the requested application page without authentication and authorization.
b. If it is Protected – the OAM 11g server constructs and returns a response back to the Webgate. That response contains the authentication scheme required to authenticate the user.
2. Next the Webgate sets a cookie (OAM_REQ) to keep track of the target/requested URL and then redirects to the OAM 11g server, which routes the request to the credential collector.
3. The detached credential collector (DCC) serves up the login page, which captures credentials and posts the credentials to the OAM server.
4. The credentials are validated against the ID store configured for this particular authentication scheme.
5. Once the credentials are validated, the OAM server creates an authentication token, the session in Coherence, and creates a server side session cookie called the OAM_ID cookie, which has details about the user, the time the session was created, the idle timeout, and session identifier to the coherence session.
6. Then the OAM server constructs a response which is encrypted with the Webgate's key and redirects to the Webgate.
7. The Webgate decrypts the response, extracts the authentication token and the session identifier, and uses that information to set OAMAuthnCookie, which is set as a host cookie: OAMAuthnCookie_. (In this step if you are using an OAM 10g webgate, the response from the server will contain the information required to set ObSSOCookie, if you are using mod_osso, the response will contain the information required to set the OHS host cookie.)
8.When subsequent requests are made from that Webgate, the authentication token is passed by the Webgate to the OAM server, which validates the authentication token, checks the validity of the OAM_ID cookie and session timeout, and does the appropriate authorization checks.
9.As the result of authorization checks, additional attributes may be added to HTTP Headers and passed to downstream applications. This is especially useful when asserting user identity and group or role information to downstream applications such as those running on Oracle Weblogic Server.
1. An OAM 11g Webgate intercepts the incoming request for a resource, determines whether the resource is protected.
a. If it is Unprotected : User will able to see the requested application page without authentication and authorization.
b. If it is Protected – the OAM 11g server constructs and returns a response back to the Webgate. That response contains the authentication scheme required to authenticate the user.
2. Next the Webgate sets a cookie (OAM_REQ) to keep track of the target/requested URL and then redirects to the OAM 11g server, which routes the request to the credential collector.
3. The detached credential collector (DCC) serves up the login page, which captures credentials and posts the credentials to the OAM server.
4. The credentials are validated against the ID store configured for this particular authentication scheme.
5. Once the credentials are validated, the OAM server creates an authentication token, the session in Coherence, and creates a server side session cookie called the OAM_ID cookie, which has details about the user, the time the session was created, the idle timeout, and session identifier to the coherence session.
6. Then the OAM server constructs a response which is encrypted with the Webgate's key and redirects to the Webgate.
7. The Webgate decrypts the response, extracts the authentication token and the session identifier, and uses that information to set OAMAuthnCookie, which is set as a host cookie: OAMAuthnCookie_. (In this step if you are using an OAM 10g webgate, the response from the server will contain the information required to set ObSSOCookie, if you are using mod_osso, the response will contain the information required to set the OHS host cookie.)
8.When subsequent requests are made from that Webgate, the authentication token is passed by the Webgate to the OAM server, which validates the authentication token, checks the validity of the OAM_ID cookie and session timeout, and does the appropriate authorization checks.
9.As the result of authorization checks, additional attributes may be added to HTTP Headers and passed to downstream applications. This is especially useful when asserting user identity and group or role information to downstream applications such as those running on Oracle Weblogic Server.
No comments:
Post a Comment