Whew, that’s a mouthful for a title, but IdP N..1 SP [OIF+OAM] was probably too cryptic. Let me describe the use-case in a little more detail. Imagine if you will an education application that the state wants to surface to the various school districts. The districts want to manage user accounts and federate into the state’s application. In order to consolidate policy enforcement for both internal and external users, the state needs a single point of entry controlled by an access control system.
The documentation for Oracle Access Manager (OAM) and Oracle Identity Federation (OIF) integration on the service provider (SP) (http://docs.oracle.com/cd/E21764_01/doc.1111/e15740/oif.htm#CACJDDGE) implies that this can only be done with a single identity provider (IdP). By setting OIFScheme as the authentication scheme for the application, OAM can redirect to the service provider on OIF, which will trigger an SP-initiated Single Sign-On (SSO). There is no way to declare which IdP to use in this scenario, however. Thus, a different trigger mechanism is required for the multiple IdP scenario, plus we need to account for internal state users as well. One approach is to leverage OAM form authentication with hyperlinks to an IdP discovery page, or static links to each campus trigger for SP-initiated SSO. The format in OIF for this is http(s)://<oif>: <oif_port>/fed/sp/initiatesso?providerid=CAMPUS1&returnurl=<URL of destination app>. Once the IdP sends its SAML Response to the OIF service provider, OIF will make authentication & authorization request to OAM Policy Decision Point (PDP) based on the returnurl parameter. If successful, OIF will redirect client to the destination application with a token that the OAM Policy Enforcement Point (PEP) will honor.
One gotcha here is that the returnurl must be protected by the OIFScheme, not the form-based scheme used for internal users. That creates a challenge in that you essentially need two protected URLs for entry into the app, one to trigger the initial form authentication and one to map the external/federated users. If having all external users end up at the same portal site after authentication is acceptable, one can map the OIFScheme to a pseudoURL. You can then configure an OnAuthenticationSuccess redirect to the landing page. This pattern is only suitable if all external users come to the same page upon successful federation. I tried basing the federation policy on a query parameter, i.e. returnurl=/mysite?external=true, but OAM did not seem evaluate the query parameter, only the application context.
Another hitch is that I don’t think a 10g WebGate can consume the identity token set by the service provider. I haven’t tested to validate, but I suspect that only the 11g WebGate can consume the OAM_ID cookie. Thus, if you have a mixed environment, you will need an OHS 11g instance to handle external user traffic, while redirecting to other web servers only after an authentication cookie has been set.
Posts
Matt,
ReplyDeleteDid you look at Custom Actions in OIF? Theoretically, you can set a custom action in OIF to change the IDP to the desired IdP. The challenge i'm facing right now is to determine the right IdP. If I can set a cookie (in OAM) or find some way of accessing the original protected URL from my OIF custom action, this should work.
1dsa,
ReplyDeleteI can speak to accessing the original protected URL. You can set a cookie in the Authentication Policy Response to be res_url (relative) and then programmatically retrieve that value. I have not thought about using custom actions in OIF to do this, however.
Sorry, that's $request.res_url to store the original URL.
ReplyDeleteI considered the Authentication Policy Response, but I thought the response actions were set only upon successful (or unsuccessful) authentications. So when OAM sends to OIF, the response actions are not triggered until OIF sends back to OAM???? OIF custom actions was the recommendation I received from Oracle Development to solve this problem.
ReplyDeleteWhat you say is true. So are you trying to use the OAM as the PEP with the OIFScheme and leverage your own IDP identifier? Something like a policy for /myapp/.../* being OIFScheme and the request would something like http://host:port/myapp/index.jsp?idp=idp1? Then have OIF determine (through custom action I suppose) which IDP to use?
ReplyDeleteSort of. We have multiple applications (different URLs) protected by the OIF authentication scheme. Each application can have different IdP requirements. So I need the ability to use a different IdP for each protected URL. We have one large OIF cluster. Functionally the same as what you said. The OIF custom action can choose the appropriate IdP...I just need to pass something to OIF to help it make the right decision.
ReplyDeleteUnderstand. Hopefully Engineering has taken this use case into account in 11.1.1.6.
ReplyDelete