multiple SAML CoTs in one IDP instance

This topic has 10 replies, 7 voices, and was last updated 4 years, 5 months ago by Scott Heger.

  • Author
  • #11961

    In case of SAML federation, on IDP side, I have 2 CoTs (CoT1 and CoT2)

    User starts at IDP-side,

    IDP initiates user-handshake with CoT1, establishes SSOToken, prepare SAMLResponse and sends it out to the ServiceProvider

    So far so good ,and user is on the service-provider’s home page.
    From that page User is hitting another link which results into

    one more request that comes to the SAME IDP, but this time CoT2 was going to do the work,
    So my Question is will the SSOToken generated previously be helpful ?
    User will be challenged again and another SSOTOken will be created.

    I do not want to configure one IdP per realm and include them in separate CoTs as shown here.


     Peter Major

    CoTs are more or less pointless, they only enforce trust relationship at the time when a SAML request is processed and only within that context. As soon as you have a session established, OpenAM forgets about CoTs altogether.
    Keep this also in mind:


    Thanks Peter for looking into it.

    I am not following your statement , you said
    “As soon as you have a session established, OpenAM forgets about CoTs altogether.”

    I am using OpenAM 13
    I have a valid SSOToken from OpenAM-IDP in CoT1 (IDP1 & SP1 & Realm1)
    Will this token be helpful to get SAMLResponse for subsequent Service Providers ?

    I doubt because next SP can send request for particular IDP-entity (/realm2/IDP2) in same or different CoT.


     Rogerio Rondini

    Hi @rob_swann,

    The problem is not the different CoT but the different Realm. In case of the authenticated user navigates to another SP whose Cicle of Trust is between SP2 and IDP2 configured in Realm2, probably OpenAM will ask for new authentication.

    OpenAM does not support SSO between realms (AFAIK).



    Thanks Rogerio.
    Yes, that is exactly what my thought-process is.

    Like you said, if user navigates to another SP whose Circle of Trust is between SP2 and IDP2 configured in Realm2, probably OpenAM will ask for new authentication.
    And now this new SSOToken will have realm2 and corresponding universal-ID etc. everything around it.

    If user navigates to another SP whose Circle of Trust is between SP2 and IDP2 configured in THE SAME Realm, then OpenAM will NOT ask to re-authenticate as long as IDP2 is not configured with higher level of authentication etc. OR SAML Request has not come with specific authentication context.
    If higher level of authentication is required then it is a case of session-upgrade.
    Same SSOToken will be upgraded.

    I hope I am correct with my understanding.



    Hello all

    Please let me know if i have multiple CoT ( One CoT for each SP ,IDP is same) in same realm with SSO work seamlessly.



    @thirujay, Yes


    OpenAM most definitely does not allow SSO between realms and some would see this as a feature… at least one of our clients does as they want to restricts users straddling applications of different realms.

    If you are logged into a realm and try to hit another realm you will be told that you are already logged in to an Organization and asked if you want to Continue Yes/No? If you say Yes then you will re-start authenticate with the new realm whereas if you say No you will keep your current authenticated session.


     Peter Major

    @thirujay CoTs are pretty much useless (as stated by me earlier in this very topic), as long as all of the entities are in the same realm, SSO will be seamless for them.

    @nikolaosgac You can have active sessions across realms if your realms are mapped to different cookie domains.


    You mean if you use different cookie domain you won’t be prompted that you are already logged in an can authenticate to have a different SSO session.

    So yes you can have active sessions across realms but regardless cannot have SSO across realms. So sure it does depend on the solution requirements.

    I often wish OpenAM was flexible in allowing SSO across realms, “in some cases” (configurable) when large enterprise clients want to have the ability to leverage realms for admin purposes (e.g. they have large application groups with dozens of Agent profiles, polices, etc… specific to only that application group AND have multiple application groups) but still want to have the ability to maintain SSO across realms. AFAIK, you need to forgo SSO unless there is something that I am missing such as say delegated admin (which I have not had the cycles to look into).


     Scott Heger

    The location of policy agent profiles and policies themselves has no bearing on which realm the user logs into. You most certainly can have your agent profiles in one realm, your policies in another, and your users log in to yet another.

Viewing 11 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic.

©2022 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?