Content Server
Chances are that if you authenticate externally, you've tested your luck with credential maps. I say "luck" because deciphering its syntax for the first time is akin to waiting in line to use the restroom: frustratingly painful. In a nutshell, credential maps are a part of the ProxyConnections8 component that allow you to link ADSGs (and their members) to Oracle UCM roles and/or accounts.
If you need a credential map that can link everything one-to-one:
use the following:
#Maps all roles|#all|, %%
#Maps all accounts@|#all|, @%%
Note: the #all term does not refer to an ADSG named #all; it is a reserved keyword to signify ALL ADSGs listed within the LDAP Role/Account Prefix OU.
As powerful as the above map is, it has one fundamental flaw:
#Maps all roles|#all|, %%
#Maps all accounts to their respective account@|#all|, @%%
#Maps #all and #none account@|all|, @#all@|none|, @#none
One caveat to credential maps is that its mappings do not override one another. That is, mappings listed at the bottom do not overwrite the ones above it; so any role or account can be mapped multiple times. Therefore, assigning a user to the "all" ADSG in the above mapping will result in a double mapping: "all" and "#all". To prevent this, the credential map needs to ignore the "all" (and "none") ADSG, like so:
#Maps all roles|#all|, %%
#Maps all accounts to their respective account@|#all -all -none|, @%%
#Maps #all and #none account@|all|, @#all@|none|, @#none
Single, Shared Active Directory
Another problem with the above mappings is that they assume you have a separate AD for each Oracle UCM instance; which explains why it can be reused. If you have an environment that uses a single, shared Active Directory, however, how would you assign someone to be an admin for development, but only a contributor for production? Even if you have a separate LDAP role/account prefix for each UCM instance, you cannot have two ADSGs with the same name (ie. "admin") because they must be globally unique.
In order to handle this, you need to map each instance individually. The simplest way is to add a prefix to each ADSG (I recommend the UCM instance name), followed by a dash (-): "dev-admin" and "prod-admin". Doing so, however, would require similarly named UCM roles. While there is nothing wrong with that, it would be ideal if we could map them both to something of our choosing; namely, just "admin". In fact, you already explicitly mapped to the #all and #none accounts in the above mappings, so we can employ the same idea.
Therefore, you can map an individual UCM instance:
by using this credential map:
#Maps all roles|#all|, %%[4]
#Maps all accounts except the dev-all and dev-none accounts@|#all -dev-all -dev-none|, @%%[4]
#Maps the "dev-all" ADSG to the #all account@|dev-all|, @#all
#Maps the "dev-none" ADSG to the #none account@|dev-none|, @#none
Note: The number in between the brackets ([ ]) is the number of characters to ignore before mapping the rest of the string (marked by %%). Make sure to change this accordingly.
In the off chance that you are using the same LDAP Role/Account prefix for all your UCM instances, you will need to change your credential map to the following:
#Maps all "dev-" roles|dev-|, %%[4]
#Maps all "dev-" accounts@|dev-|, @%%[4]
#Maps the "dev-all" ADSG to the #all account@|special/dev-all|, @#all
#Maps the "dev-none" ADSG to the #none account@|special/dev-none|, @#none
Things to note:
1. The "dev-none" and "dev-all" accounts are in a "special" OU group because we don't want them mapped twice. You can certainly change the name to something that won't be affected by the first mapping, @|dev-|, @%%[4], but I chose to keep the same naming structure for consistency sake.
2. I chose the name "special" for the separate OU group, but it can be any qualified name.
I've hopefully covered everything; if not, here's one last, but very helpful tip:
While the 'at' symbol (@) indicates accounts and no 'at' symbol indicates roles, there is nothing that prevents you from mapping them with each other. In other words, you can map roles to accounts, and vice versa.
For instance, if you have a "prod-intern" role that should always be given (R)ead access to the Corporate account, you would have the following:
|prod-intern|, @Corporate(R)
By using this approach, you would never need to manually assign users to the "prod-Corporate_R" ADSG; or even create one for that matter. You can't even do that with the User Admin Applet. Think of the possibilities!
I chose to highlight this because I don't think many people realize it.
Good luck!
Good luck!
No comments:
Post a Comment