This topic has 2 replies, 2 voices, and was last updated 5 years, 6 months ago by 
.
-
Posts
-
Hello, I am developing my organization’s OpenAM architecture. I am trying to decide what is the best initial Realm architecture. The initial installation, and my initial configuration has my datastores and authentication happening in the root realm. But as I consider the uncertain future, it occurs to me that this may not be the best long-term strategy. Perhaps I should leave the root Ream empty (with the exception of the embedded Datastore repository), and configure my (current) production environment to use a sub-Realm.
What are best practices with respect to Realms? What do most people do? If requirements changed how difficult would it be to create a new sub-realm and migrate the Realm settings down?
Hi,
As a best practice you have to avoid use top realm, even you need a single one. So, in this sense I think you should move your current production configuration to a sub-realm.
The difficult will be according to what you have so far. If you have Policy Agents you will need to change the Login URL to point to the Realm; If you are using REST API you will need to add the realm information in the REST call… and so on.
K.R,
Rogerio.Hi Rogerio, thank you for your thoughts! Would it be appropriate to use the OpenAM user data store for the root realm, and then configure Active Directory (my production user data store) in the sub-realm? I anticipate very centralized administration of my OpenAM deployment, but there is a possibility that other Realms with other data stores may be necessary.
I’m a bit concerned because the OpenAM installation GUI suggests, “A good practice for setting up production environments is to use and external user data store, one that is different than the OpenAM user data store.” But I’m wondering if/how that advice applies to a root realm (which is, in fact, what the GUI is setting up).
You must be logged in to reply to this topic.
