All the web-tier related files like .jsp, .class, JSPCompiled files, etc gets stored in a directory. This is treated as cache whenever restart of WebLogic instance happens then the WebLogic server will look-up for last serviced object status stored in the cache to service for any pending requests. Usually, when your EJB Classes need sessions, JMS object requires persistance, your web-tier may contain static contents then Cache will be used by WebLogic Application Server instance.
Whenever your application is accessed for the first time after fresh deployment of a new version, WebLogic server lookup in this 'tmp' cache directory, if there older objects exists then it will conflict with new code objects. This is where the need of removal of cache arises. When there is a need of new version deployment we might need to clear the cache when the changes to the new version is not reflected.
In Weblogic Server version 9.x & 10.x removal of cache means deleting each server instance's 'tmp' folder contents or you can simply remove 'tmp' folder too provided there should not be configuration changes happening to the server.
Below example clears the weblogic managed server cache for Oracle Access Manager OAM.
[sami@srv tmp]$ pwd
/u03/oracle/mwoam/user_projects/domains/IAMDomain/servers/oam_server1/tmp
[sami@srv tmp]$ ls -ltr
drwxrwxrwx 27 sami dba 4096 Feb 28 08:11 _WL_user
drwxrwxrwx 9 sami dba 4096 Feb 28 08:11 _WL_internal
-rwxrwxrwx 1 sami dba 687 Mar 6 12:21 WebServiceUtils.ser
-rw-r----- 1 sami dba 0 Mar 18 12:04 oam_server1.lok
[sami@srv tmp]$ rm -rf /u03/oracle/mwoam/user_projects/domains/IAMDomain/servers/oam_server1/tmp
For any queries and help related to weblogic server administration, please don't hesitate to contact me. samiora@gmail.com
Tuesday, March 25, 2014
Thursday, March 20, 2014
Oracle Access Management SSO
Oracle Access Management SSO
Single Sign-On (SSO) allows users to log in once and gain access to all systems protected by the same SSO solution without being prompted to log in again.
OAM SSO login request flow
Applications protected by OAM SSO can use one of following three agents, OAM 11g WebGate—OAM 10g WebGate, or OSSO Agent—as a policy enforcement point (PEP). The login request flow for applications protected by OSSO is slightly different than the ones protected by 10g/11g WebGate. OSSO uses only authentication policies, whereas 10g/11g WebGate uses both authentication and authorization policies.
SSO login request flow with OAM 11g agents (WebGate)
1. The user requests a resource on the web server, which is protected by WebGate
2. WebGate forwards the request to the OAM server
3. OAM checks:
Whether the SSO cookie is present in the request or not
The authentication policy, to determine if the resource is protected and how?
4. OAM logs and returns the decision to WebGate
5. WebGate responds as follows:
If the resource is protected, then user is presented with the login form based on the authentication policy (move to step 6)
If resource is unprotected, then the resource is presented to user
6. User sends their credentials
7. OAM server verifies the credentials.
If the credentials are correct, then OAM starts the session and creates SSO cookies (move to step 8)
If credentials are incorrect, then the login form is again presented to the user (move to step 6)
8. Credential collector redirects to WebGate and the authorization process begins
9. WebGate asks OAM to look for the authorization policy, compare them to the user's identity, and determines if the user is authorized to access the resource
10. OAM server checks the session, evaluates policies, and caches the result
11. OAM logs and returns the authorization policy decision to WebGate
12. WebGate responds as follows:
If the user is authorized to access, the resource is presented to them
If user is not authorized to access, the user is redirected to the URL mentioned in the Failure URL field of the authorization policy
OAM SSO cookies
A cookie is a piece of text stored by a user's web browser. Cookie are used to maintain data related to the user during navigation across multiple visits. OAM maintains various cookies that can be set or cleared during user login. The cookies set or cleared by OAM are OAM_ID, OAMAuthn, ObSSO, OAM_REQ, OAMRequestContext, OHS-, and GITO.
For any queries please email me, samiora@gmail.com.
Single Sign-On (SSO) allows users to log in once and gain access to all systems protected by the same SSO solution without being prompted to log in again.
OAM SSO login request flow
Applications protected by OAM SSO can use one of following three agents, OAM 11g WebGate—OAM 10g WebGate, or OSSO Agent—as a policy enforcement point (PEP). The login request flow for applications protected by OSSO is slightly different than the ones protected by 10g/11g WebGate. OSSO uses only authentication policies, whereas 10g/11g WebGate uses both authentication and authorization policies.
SSO login request flow with OAM 11g agents (WebGate)
1. The user requests a resource on the web server, which is protected by WebGate
2. WebGate forwards the request to the OAM server
3. OAM checks:
Whether the SSO cookie is present in the request or not
The authentication policy, to determine if the resource is protected and how?
4. OAM logs and returns the decision to WebGate
5. WebGate responds as follows:
If the resource is protected, then user is presented with the login form based on the authentication policy (move to step 6)
If resource is unprotected, then the resource is presented to user
6. User sends their credentials
7. OAM server verifies the credentials.
If the credentials are correct, then OAM starts the session and creates SSO cookies (move to step 8)
If credentials are incorrect, then the login form is again presented to the user (move to step 6)
8. Credential collector redirects to WebGate and the authorization process begins
9. WebGate asks OAM to look for the authorization policy, compare them to the user's identity, and determines if the user is authorized to access the resource
10. OAM server checks the session, evaluates policies, and caches the result
11. OAM logs and returns the authorization policy decision to WebGate
12. WebGate responds as follows:
If the user is authorized to access, the resource is presented to them
If user is not authorized to access, the user is redirected to the URL mentioned in the Failure URL field of the authorization policy
OAM SSO cookies
A cookie is a piece of text stored by a user's web browser. Cookie are used to maintain data related to the user during navigation across multiple visits. OAM maintains various cookies that can be set or cleared during user login. The cookies set or cleared by OAM are OAM_ID, OAMAuthn, ObSSO, OAM_REQ, OAMRequestContext, OHS-
For any queries please email me, samiora@gmail.com.
Subscribe to:
Posts (Atom)