This content has been marked as final. Show 11 replies
Multiple Application can be protected using same scheme, the applications would be identified using a unique identifier.
A typical example for multi-tenancy in OAM would be to allow user to select his organization while logging in and based on his selection on the login screen, he will be authenticated against the User Identity Store of that particular organization. I think there is similar example in some Metalink document that you may refer to for more details.
Let me know if you need more clarification.
Thanks to both for responding, but it seems like both of your answers are different?
I configured a FederationMTScheme and FederationMTPlugin in OAM (11gR2), just to see what happens.
The first step in the module has an TenantDisambiguationPlugin, and that has one parameter, "KEY_FEDERATED_TENANTS".
Then, there are step-pairs for Local user identification/authentification and for federated authentication/assertion.
When accessing a resource protected with that scheme/module, the first page that appears says "Sign in" with a label of "Tenant Name".
If I could understand what is suppose to be put into that "KEY_FEDERATED_TENANTS" parameter in the plugin, it might be easier to comprehend what this is suppose to do and how it's suppose to work.
P.S. If you could provide the article id for that metalink article, I'd appreciate it. I've been searching different places, including metalink, but most of the hits refer to multi-tenancy in OAAM.
P.P.S. The thing that is making this really confusing is that, regardless of what I enter into that initial web page, everything appears to behave exactly the same.
So either I have the plugin configured incorrectly for it to do what it's suppose to do, or...?
Here you go:
OAM 11g : How To Set Up OAM 11g Version 18.104.22.168 To Support Users Selecting Their Organisation Via The Login Screen. [ID 1342856.1]
Refer to this document and replace the organization with Tenant for your context. Let me know if you have more questions.
Thanks for the metalink article. I've read that, and I can understand what the article is describing, but I'm not 100% clear how that relates to the configuration parameters in the FederationMTPlugin. The article talks about a mapping file, but I don't see something like that for configuring the TenantDismbiguationPlugin?
The first step in FederationMTScheme plugin is a TenantDisambiguationPlugin, which takes two parameters:
KEY_FEDERATED_TENANTS (a comma-separated list of "some things")
The steps/orchestration for the FederationMTPlugin has:
Initial Step: FedUserAuthenticationPlugin
TenantDisambiguationPlugin OnSuccess: FedAuthenticationPlugin OnFailure: UserIdentificationPlugin
UserIdentificationPlugin OnSuccess: UserAuthenticationPlugin OnFailure: failure
UserAuthenticationPlugin OnSuccess: success OnFailure: failure
FedAuthnRequestPlugin OnSuccess: success OnFailure: FedUserAuthentication
FedUserAuthenticationPlugin OnSuccess: success OnFailure: TenantAmbiguationPlugin
[The OnError results for all steps are failure, so I haven't shown them.]
So, the first step is the FedUserAuthenticationPlugin (AssertionProcessing), and if that fails, the next step is the TenantDisambiguationPlugin.
I guess all of my questions are around what that TenantAmbiguationPlugin does, and how it works?
I'm guessing that what you enter on the 1st webpage, which asks for a Tenant, is matched against the comma-separated list that is in the plugins "KEY_FEDERATED_TENANTS" parameter.
Is that correct?
a) What happens if there is a match of what you entered vs. what's in the "KEY_FEDERATED_TENANTS" list?
b) What happens if there is NOT a match of what you entered vs. what's in the "KEY_FEDERATED_TENANTS" list?
That article you mentioned calls for a mapping file, that maps what is entered (the tenant) to a user identity store, but where is that in the TenantDisambiguationPlugin's parameters? The only other parameter for that plugin is the "KEY_IDENTITY_STORE_REF" parameter.
Having said that, I described the steps and step orchestration in the FederationMTPlugin above. If the TenantDisambiguationPlugin is suppose to somehow map what's entered to a user identity store name, then, with respect to the FederationMTPlugin, is that mapped user identity store used for the UI and UA steps (i.e., as the "KEY_IDENTITY_STORE_REF" for the UI and UA steps)?
Thanks for your help with this. Oracle's documentation certainly merits some improvement :(...
I've been doing more testing, and I think that I've figured out PARTLY how that TenantDisambiguationPlugin works.
If I put a list of the names of the IDPs that I have configured in OAM into the KEY_FEDERATED_TENANTS parameter, then, when I get to the first web page of the FederationMTPlugin Module, and enter one of those name into the "Tenant" text box, then OAM (and OIF) causes my browser to be re-directed to the form login page of the IDP whose name I entered.
For example, I have two OIF domains, say DOMAIN1 and DOMAIN2, and in DOMAIN2, I have an OAM (the "DOMAIN2 OAM"), and I have the IDPs named as "DOMAIN1-IDP" and "DOMAIN2-IDP" in the DOMAIN2 OAM. So, when I get to the Tenants web page, if I put "DOMAIN1-IDP" in for "Tenant", I get the login page from the DOMAIN1 IDP.
After I enter a good username/password for DOMAIN1, the browser gets re-directed to my original target.
If I enter a string for "Tenant" that doesn't match "DOMAIN1-IDP" or "DOMAIN2-IDP", then the browser gets re-directed to a login page on the DOMAIN2 OAM itself, and then if I enter a username/password, it appears that, per the flow, that DOMAIN2 OAM attempts to authenticate me locally first, then if that fails, I guess that it'll re-direct the browser to the default IDP provider on the DOMAIN2 OAM.
The part that I'm still unclear about is what is the function/role of the "KEY_IDENTITY_STORE_REF" parameter in the TenantDisambiguationPlugin? It doesn't seem to come into play at all?? PLUS, what's weird is, actually, that "KEY_IDENTITY_STORE_REF" parameter SOMETIMES appears in the TenantDismbiguationPlugin's configuration parameters, and then, SOMETIMES, it disappears completely. That last part may be a bug, and maybe the TenantDisambiguationPlugin shouldn't have a KEY_IDENTITY_STORE_REF parameter at all?
Can anyone explain what that KEY_IDENTITY_STORE_REF parameter in the TenantDisambiguationPlugin is for? I can't see any visible difference regardless of what I set that to in my testing.
The parameter KEY_IDENTITY_STORE_REF specified the identity store to be referred. You can configure here the instance name of the identity store, if you want to use it
KEY_IDENTITY_STORE_REF also most plug-ins require this attribute to ensure that the appropriate user identity store is called during authentication.
Please let me know if it helps and what else you need clarification,
I already understand that, in general, should be a name of an identity store in OAM, but my question was really "What is the identity store that is name in 'KEY_IDENTITY_STORE_REF' parameter USED FOR in the context of the TenantDisambiguationPlugin?".
It appears that even Oracle isn't sure at this point (I have an SR) :(...