IG for internal and external Apps

This topic contains 5 replies, has 3 voices, and was last updated by  Kabi Patt 3 months, 3 weeks ago.

  • Author
    Posts
  • #20961
     Nav 
    Participant

    Hello folks,

    I have a use case of using IG as Proxy gateway at the front and to delegate the authentication and authorization decisions.

    In my scenario, I have two kinds of applications that need to protected with IG.
    1) Internal applications accessed by internal employees who can be authenticated against our own IDStore like AD (here I am delegating both AuthN&AuthZ decisions to my internal OpenAM platform).
    2) External applications accessed by partner/customer users for those authentications will be delegated on their end and would like to enforce authorization against my AM(here I would like to delegate AuhtN to external IDP and AuthZ to my internal OpenAM platform).

    Here are some of questions that I have while implementing OpenIG with OpenAM.
    1) For internal apps, how can IG pass the user authentication information to the actual backend application in secured way? Does it has to be only through “Password Replay and POST on login form” or any other ways of passing this user information to the backend application.
    2) For external applications, If I go thru SAML implementation by making IG as Service Provider and have the users authenticated with external IDP, What is the best practice of passing authenticated user information to the backend application once the SAML response is posted to IG (may be similar to above question).
    3) Can we enforce any authorization against OpenAM(this is to verify customer user access level whether he can access the app or not before even landing the user on App) once the SAML assertion response is received at Service provider(IG) before redirecting to backend application?
    4) Can multiple IGs deployed and integrated with same OpenAM hoping SSO will still work with support of cookies?

    Would like to hear suggestions and best practices around here?

    Thanks in advance,
    Nav

    #21012
     Joachim Andres 
    Participant

    Hi Nav,

    1.) The most “popular” method to push user attributes to the backend application is via HTTP header attributes and a HeaderFilter. If security is a concern, you can secure the communication between IG and the backend in the ClientHandler configuration (SSL, mutual SSL, etc.) or even place an IG “close” to each backend (microgateway style: https://www.forgerock.com/blog/microgateways-zero-trust-security-for-the-microservices-world/). Below an example of a HeaderFilter. You can also create a HeaderFilter with IG studio and just set the config part:

    {
              "name": "HeaderFilter-InjectUserAttributes-1",
              "type": "HeaderFilter",
              "config": {
                "messageType": "REQUEST",
                "add": {
                  "mail": [
                    "someaddress"
                  ],
                  "empid": [
                    "somevalue"
                  ]
                }
              }
    }

    2.) Yes, same principal as in 1.). You can map SAML assertion attribute to IG session attributes which can then be used in the HeaderFilter. See the assertionMapping and sujectMapping parameters in the SamlFederationHandler (https://backstage.forgerock.com/docs/ig/5.5/reference/index.html#SamlFederationHandler)

    3.) In principal, yes, in a PolicyEnforcementFilter. You need to figure how to pass the subject to AM’s policy service. I suppose that you do not have an SSOtoken at this point. So you can pass the user subject either as a jwtSubject or as a claimsSubject. Probably a claims subject could do if the username was obtained via a SAML assertion and extracted as mentioned in 2.). Please see https://backstage.forgerock.com/docs/ig/5.5/reference/index.html#PolicyEnforcementFilter

    4.) Sure. You can have multiple IG instances of course. You can even have one (set of) IG instance(s) per backend application or per group of backend applications which all point to the same AM service, which in itself can be composed of many AM instances.

    Concerning internal and external applications, typically the user populations are in different AM realms where each realm may have different authentication and authorization procedures. If an application is internal, point the SSOFilter and PolicyEnforcementFilter to the internal realm, and so forth.

    Cheers,
    Joachim

    #21014
     Joachim Andres 
    Participant

    Hi Nav,

    Forgot to mention, you can also use a CryptoHeaderFilter which allows to encrypt the HTTP header attributes.

    See: https://backstage.forgerock.com/docs/ig/5.5/reference/index.html#CryptoHeaderFilter

    Cheers,
    Joachim

    #21097
     Nav 
    Participant

    Thanks Joachim for the detailed explanation and the possibilities. Basically, we do not want to use password replay option to log in to backend applications.As per the above-given possibilities, HeaderFilter and CryptoHeaderFilter are one way of communicating authenticated user identity information to backend applications.

    If IdentityGateway acts as OAuth2 Relying party, Can it also deliver the user identity and access level information as part of “id_token/access token” along with authorized “scopes” issued by “AccessManager Auhtz server”?

    Not sure once IG validates access token, whether it can still pass token back to application or should it have to convert to headers only and communicate to application?

    Thanks,
    Nav

    #21168
     Joachim Andres 
    Participant

    For completeness (has been answered in other thread), yes, IG validates access tokens using token introspection or token info endpoints. It can pass the full token or parts of the token (claims, scopes) to downstream application.

    Joachim

    #25855
     Kabi Patt 
    Participant

    Basically, we do not want to use password replay option to log in to backend applications.As per the above-given possibilities, HeaderFilter and CryptoHeaderFilter are one way of communicating authenticated user identity information to backend applications.

    Hi Joachim
    Thank you for sharing your insight. Few follow up questions on the above said.
    (1) The encryption key need to shared between IG and the backend application When CryptoHeaderFilter is used. Correct ? Is there any other approach than sharing a key ?

    (2) What if the backend application cannot read/ consume the user-info passed in the header. There are legacy applications where there is no customization (of reading user info) is possible. What could be the solution for such app ? Is Password-Replay is the right approach for such apps?

    Thanks,
    Kabi

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

You must be logged in to reply to this topic.

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