Yes, OAAM Admin is a standard web application and uses container provided Authentication out of the box. Since OAAM Admin works with predefined Roles (CSR, CSR Manager so on), the identity store used by OAM should have user & role mappings. The OAAM Admin guide contains these details. Simply assume that OAAM admin console is a generic web application deployed on an application server. And then a customer wants OAM SSO on the admin console. Hence, a web server proxy is needed and then a webgate on the proxy web server and then connector on the app server to perform identity assertion.
This is pretty much standard integration for OAM that we support for any custom application. This case is simply more special because the custom application turns out to be OAAM.
There are a number of anti-phishing features of OAAM. Phishing attacks are often aimed at credential theft. A Phishing site will usually send the users to the real site once they steal their credentials so the user does not suspect anything has gone wrong. When this happens OAAM can recognize that the user is coming from a referral URL not sanctioned by the bank. When OAAM sees this it can add the user to a “phishing victims” group. Membership in this group will increase their risk when attempting transactions such as a wire transfer. As well an investigation case will be created so the referral URL and the user can be evaluated. If all is OK the URL can be white listed and the user removed from the group. There are also a number of other symptoms of credential theft that OAAM can detect. Factors such as max velocity, device and location usage can be very valuable in determining risk that an access attempt is not from the valid user.
To protect against fraudulent transactions occurring over hijacked sessions, Adaptive Strong Authenticator can be easily deployed in session during a sensitive transaction. This requires a human interaction (entering a PIN/OTP/Password on a PinPad/KeyPad) in a process which an automated attack cannot easily navigate using software. For example, the destination account number in a wire transfer transaction could be entered using a PinPad to prevent an automated attack from alerting the account number. Adaptive Risk Manager offers extensive protections against fraudulent transactions in session. Once a login has cleared our pre-authentication security gateway (computer and location fraud patterns) and has authenticated successfully with the proper credentials, there are still multiple strong security gateways remaining, within the Adaptive Risk Manager model.
Auto-learning is a set of functions in OAAM that profiles behavior. The behavior of users, devices and locations themselves are recorded and used to evaluate current behavior. For example, OAAM can profile a user based on login time. If John logs in between 8am – 10am 87% of the time then the risk level is elevated if he is attempting to login at 2am. In other words he is outside of his normal login time profile.
The mechanism here is same as how the multi domain SSO works. Importantly, all of the activities for form authentication are carried out between the browser and one web server. Now, suppose you want to access a resource http://www.B.com/pageB.html but still be authenticated by the login form on http://www.A.com.
The authentication scheme required by pageB needs to have a redirect URL set to http://www.A.com.
The WebGate at http://www.B.com redirects you to the NetPoint URL obrareq.cgi on http://www.A.com, with a query string that contains the original request (wu and wh).
The WebGate on http://www.A.com will determine that you need to do a form login for that resource, so it will set the ObFormLoginCookie with the wu and wh values from the query string, but will set the ru field to /obrareq.cgi. WebGate on A then redirects your browser to the login form on A.
When you post your credentials back to A, the ObFormLoginCookie is set back. WebGate on A authenticates your userid and password, sets the ObSSOCookie for the .A.com domain and redirects you back to the ru value from the ObFormLoginCookie, which is /obrareq.cgi.
Step 1: The user logs in to the identity provider using an ID and password for authentication. Once the user is authenticated, a session cookie is placed in the browser. Step 2: The user then clicks on the link to view an application residing on the service provider. The IdP creates a SAML assertion based on the user’s browser cookie, digitally signs the assertion, and then redirects to the SP. Step 3: The SP receives the SAML assertion, extracts the user’s identity information, and maps the user to a local user account on the destination site. Step 4: An authorization check is then performed and if successfully authorized, redirects the user’s browser to the protected resource. If the SP successfully received and validated the user, it will place its own cookie in the user’s browser so the user can now navigate between applications in both domains without additional logins.
IDP is the site that authenticates the user and sends an assertion to the destination site or SP. SP is the site that consumes the assertion and determines the entitlements of the user and grants or deny access to the requested resource.
There are couple of differences and are listed below.
Multi domain SSO can happen if the applications are residing in different domains within same organization or a company. Federation happens if the applications are residing within same organization as well as between organizations.
In Federation, there is a trust established between both the providers residing in different domains, whereas in Multi Domain SSO, trust is not established.
The mechanism used in MD – SSO is cookie and is SAML Assertion in case of Federation.
The attributes passed in the header cannot be encrypted OOTB in MD-SSO where as it can be digitally signed.
There is more of security involved along with interoperability in case of federation.