November 9, 2016 at 12:03 pm #14141Manchanda, PParticipant
Respected OpenAM Experts,
I have created a Realm on my OpenAM. The name of this realm corresponds to my customer name. This realm is Federated i.e. it acts as a SP to the Customer’s IdP. The customer’s IdP is outside of my network (and control).
I have a use case that requires me to rename this realm to correspond to the changes at customer end. So, I want to understand whether:
# this is feasible
# what are the repercussions like will Federation (CoT configuration) continue to work at SP and IdP end or would require reconfiguration
# APIs available to rename the same (I have seen few defects related to this)
I am inclined to understand the feasibility of renaming before moving to solution of making the realm customer agnostic, as this has its complexity in our design.
Thanks and Regards
P ManchandaMarch 31, 2017 at 2:21 pm #16629Manchanda, PParticipant
The use case that we are trying to solve is that when we change the existing realm or create a new realm, the customer should not be required to make any changes on the IdP side. Will a sub realm solve this. Say, I create a realm that federates to the customer’s IdP. Then I create a sub realm that inherits all the configurations of its parent. My question would be:
Will sub realm also inherit the CoT configurations of its parent.
Thanks.March 31, 2017 at 4:43 pm #16632nikolaosinlightParticipant
We use sub realms a lot for the Application portion of our SP configuration and moreover configure a separate COT in each of our sub realms and would love to simply inherit it but I am quite certain it is not possible. We haven’t tried it since the OpenAM SAMLv2 auth module which we use in the Application sub realm requires that the COT is defined in the same realm – so no point in testing what won’t work.
To answer your question I would say: No. Again, despite being a great feature and not having not tested it I would find it very surprising if a sub realm could inherit the COT because of a number of reasons including but not limited to the complexities of supporting things like the numerous SAMLv2 endpoints.
You must be logged in to reply to this topic.