Everything works fine now with the base portal server.
Now you may have different VPs configured on one server.
That introduces two changes.
Even if a user is found in the connected repositories the user still may not be valid for the current VP realm.
A user might be valid for VP1 but still is a transient user for VP2.
So the VMM search need to get extended to lookup users in special realms to not cross over logins of VP1 to users in VP2 e.g. based on a email address.
If a user is not valid for the current vp realm a transient DN need to get constructed to allow this user to work with portal.
By seperation of VP configurations a transient users of VP1 should not be automatically allowed to visit VP2 as transient user as well.
And if a user is transient there must be a identifier in the DN to add this transient user only to the requested and approved VP.
This identifier need to get provided for each SAML TAI config - so a reuse of a property here is the easiest way.
Configuration here requires several pieces that work together.
Usual each VP will have a own SAML provider flow - so extend the TAI config.
Of course the IdP need to have this new federation as well.
Extend buildgroupsfor feature for VP scoped transient users
You may need one AC group for each VP, so extend the configuration to include for example: vp1realm, vp2realm
Configuration of VMM realm
Add two additional FileBased repositories to the landscape by copy them into
After they are available as federated repositories the realms need to get configured (also the files are provided as example in the attached zip file).
/opt/IBM/WebSphere/wp_profile/ConfigEngine/ConfigEngine.sh wp-create-realm -DWasPassword=wpsadmin -DparentProperties=/opt/IBM/addRealmVP1.properties
/opt/IBM/WebSphere/wp_profile/ConfigEngine/ConfigEngine.sh wp-modify-realm-defaultparents -DWasPassword=wpsadmin -DparentProperties=/opt/IBM/modifyrealmparentVP1.properties
/opt/IBM/WebSphere/wp_profile/ConfigEngine/ConfigEngine.sh wp-add-realm-baseentry -DWasPassword=wpsadmin -DparentProperties=/opt/IBM/addrealmbaseentryVP1.properties
/opt/IBM/WebSphere/wp_profile/ConfigEngine/ConfigEngine.sh wp-add-realm-baseentry -DWasPassword=wpsadmin -DparentProperties=/opt/IBM/addrealmbaseentryVP1_transparent.properties
/opt/IBM/WebSphere/wp_profile/ConfigEngine/ConfigEngine.sh wp-create-realm -DWasPassword=wpsadmin -DparentProperties=/opt/IBM/addRealmVP2.properties
/opt/IBM/WebSphere/wp_profile/ConfigEngine/ConfigEngine.sh wp-modify-realm-defaultparents -DWasPassword=wpsadmin -DparentProperties=/opt/IBM/modifyrealmparentVP2.properties
/opt/IBM/WebSphere/wp_profile/ConfigEngine/ConfigEngine.sh wp-add-realm-baseentry -DWasPassword=wpsadmin -DparentProperties=/opt/IBM/addrealmbaseentryVP2.properties
Now the realms are prepared.
After a restart of the server leverage the portal administration to create the VPs with the provided realm vp1realm, vp2realm
There is a code update required to support the VP scoping discussed in the next post.