Locking down OpenAM admin console – How are you guys doing this?

Tagged: 

This topic has 9 replies, 6 voices, and was last updated 1 year, 3 months ago by Andy Cory.

  • Author
    Posts
  • #7021
     andyr
    Participant

    Just wondering what methods people are using to restrict access to the OpenAM admin web interface, while still allowing users to login via the web interface?

    #7022
     Brad Tumy
    Participant

    The recommended approach is to install the server-only version of OpenAM. You can than install an instance with the console on another server that is restricted to access only by the admin group.

    https://backstage.forgerock.com/#!/docs/openam/12.0.0/install-guide/chap-install-core

    #7023
     andyr
    Participant

    Thanks Brad.

    Do we know if this will still be the case with version 13?

    #7024
     Brad Tumy
    Participant

    I am not an authoritative source but it’s a pretty important feature so I would be surprised if it was deprecated. You should be able to check out the nightly build to verify if openam-console and openam-server directories are still present.

    Nightly Builds:
    https://forgerock.org/downloads/openam-builds/

    You can browse the source here as well:
    https://stash.forgerock.org/projects/OPENAM

    #7025
     andyr
    Participant

    Thanks Brad. I’m currently using the nightly build (which seems to have changed to v14) and couldn’t see any OpenAM-ServerOnly war files. Hopefully these will be included when this reaches release status.

    #7042
     Peter Major
    Moderator

    The server-only mode has been deprecated. With the introduction of the XUI admin console, the separation of admin/user stuff is mostly gone, hence it would be difficult to come up with such WARs as well (not to mention the fact that server-only always exposed the same REST APIs as the full WAR, so just removing the XUI admin console won’t resolve the problem with all the config related REST endpoints being available).

    #7048
     Bill Nelson
    Participant

    Peter, couldn’t you take another approach, outside of the OpenAM application to address this?

    For instance, place OpenAM behind a reverse proxy and limit access to certain URLs – i.e. REST endpoints for managing configuration – from external users or even perform URL rewrites in the RP for URLs that might be considered sensitive or that pass certain query strings.

    Another option could be to update the servlet filters that protect certain REST endpoints to only allow traffic from internal users (rather than external users).

    Thoughts?

    #7105
     Peter Major
    Moderator

    I suppose as long as there is a need for this kind of deployment, there is a good chance that some kind of new interpretation will be introduced in one of the upcoming releases.

    #25669
     ddil
    Participant

    Does OpenAM 6 provide a solution for a user console?

    #25706
     Andy Cory
    Participant

    No, the admin console and user-facing pages are still part of the same WAR application. IMO, the preferred solution is to whitelist endpoints using a reverse proxy as @bill-nelsonidentityfusion-com suggested (3 years ago). Or in an enterprise environment you may have the option to do the same thing on an F5 device, for example.

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

You must be logged in to reply to this topic.

©2020 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?