One openAM instance, multiple realms

Tagged: , ,

This topic has 7 replies, 4 voices, and was last updated 5 years, 2 months ago by Peter Major.

  • Author
  • #17963

    I wanted to know if this pattern was achievable.

    I want to setup one openAM/openDJ instance, have two realms, and allow a user to authenticate to either or both realms.

    Can or will each realm have its own distinct cookie to allow SSO (single sign on) to exist for each realm at the same time? Or will both realms share the same cookie, and if so, how can we maintain the separation of two distinct SSO tokens?

    • This topic was modified 5 years, 2 months ago by Peter Major.
     Peter Major

    There is only one session cookie in OpenAM, however you can play around with cookie domains. In essence you can configure realm x and realm y with DNS alias foo and DNS alias bar. When you access OpenAM on foo domain you’ll have a session cookie set for foo domain, and when you access the bar domain for realm y, your session won’t be visible, hence you can authenticate there as well and get a different session cookie for bar domain.


    There is no option to separate realms and have same cookie for both of them.

    If you want to use multitenant login at the same time. You have to have as many instances of OpenAM as you want to have tenants in case what Peter mentioned that cookie is global setting for OpenAM configuration.

    Another question is if you really need another realm for it. If user can log into both realms there is question if there is no option to use one identity and divide behaviour of “different realms” by authorization layer. To be more specific just tell consumer for which “realm actions” has your identity rights

     Scott Heger

    Peter’s suggestion of using a different DNS alias for each realm is probably the way to go. It would be interesting to hear how you are using each of the realms. Can you share a use case for a user that would want or need to log into multiple realms? Based on that there may be alternate approaches to solving the use case.


    I can give you a one example.

    Imagine that company have three different types of users which are using different datastores (multiple identities).

    But company dont want to use three instances of OpenAM with different configuration just wanna use realm to explicitly define different tenant which will create for example another cookie with different name.

    Live example should be usage OpenAM for customers and for internal users. Configuration and installation is same, no need to use another machine, VM, container and so on.

    If there is an option to make it by using web agent or somehow else i will be glad to think about it and implement it.

     Scott Heger

    Right, that is the classic use case for realms. I assume then you are referring to a situation where a user would be both a customer and an internal user and have a need to authenticate to different applications that use the different realms at the same time. Is that an accurate assumption? What other differences do you have on a per realm basis? Is the UI different? Other services in OpenAM configured differently per realm?


    As an Identity Provider (IdP), we want to offer two types of SAML federations that Service Providers (SP) would leverage for users:

    1) a “Citizen” user specification (Identity and Credential)
    2) a “Business” user specification (Identity and Credential)

    The idea of having two realms each with their own distinct SSO token under one openAM, would allow a given user in one browser instance to login as a “Citizen” user with one SP (federated as a Citizen SP) while also allowing the same user to login as a “Business” user with another SP (federated as a Business SP).

    I hope this makes sense, otherwise, I can elaborate further. Otherwise, will this be possible with openAM?

     Peter Major

    Just use different cookie domains for the different realms. You won’t be able to be authenticated in more than one realm otherwise.

Viewing 8 posts - 1 through 8 (of 8 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?