OpenAM: Authentication requirements for authorization decisions

Tagged: , ,

This topic has 4 replies, 3 voices, and was last updated 7 years, 3 months ago by Gregory Wright.

  • Author
    Posts
  • #4508
     Gregory Wright
    Participant

    We are evaluating OpenAM as an entitlements provider for not only protecting web applications and services, but also supporting authorization for access to data being exposed by web services. At its simplest:

    User --> Web App --> Web Service --> Database

    Where the User submits a query through the Web App, and the Web Service needs to decide if the data selected by the query can be returned to the User, based on the User’s identity. Identity within the target environment is provided through the use of client PKI certificates issued from trusted CAs.

    In reading the OpenAM documentation (and looking through the wiki), it appears that:

    1. The User needs to authenticate directly to OpenAM (or an OAuth2 or SAML-based service within an OpenAM circle of trust)

    2. The User’s authentication token / credentials will need to be passed to the Web App and Web Service

    3. The Web Service will then request an entitlement decision from OpenAM on the data being returned for the query, using the Users token.

    Is this the case, or am I missing a simpler interface for requesting such a decision? Or am I missing the boat entirely?

    One additional wrinkle here is the use of Spring Boot with the embedded Jetty servlet engine, which seems to preclude the use of an OpenAM web agent for the authentication.

    I am putting together a more detailed description of what we’re doing, but wanted to at least have a fundamental understanding of how applications interface with OpenAM on behalf of end-users for this purpose.

    Thank you in advance,
    Greg

    #4515
     Manchanda, P
    Participant

    @Greg,

    There are Java EE Agents available for OpenAM that can be installed on containers like Tomcat/Jetty etc. The docs are available here

    Thanks and Regards
    P Manchanda

    #4522
     Gregory Wright
    Participant

    I know there are JEE agents, which from what I can tell handle the authentication and authorization for access to the URL of a web service or application. It is implemented as a filter, which in my experience equates to deciding access at a somewhat coarse / medium level of granularity for access to a specific web resource. But a significant part of what we’re trying to do here is in the business layer of the application, where we need to either:

    – Decide before a query is issued to the database whether the user can have access (e.g., based on elements of the URL that translate into database keys, we can build a resource identifier

    – Decide after a query returns data from the database which rows can be returned to the user

    This to me implies a direct call to a Policy Decision Point with the requesting user’s identity (subject), the resource(s), and an action of “query” or “read” within the business layer to obtain the decision. My questions then are:

    – How do I need to pass in the requesting user’s identity so that OpenAM will recognize it as an authenticated identity?

    – Does the identity need to be authenticated by OpenAM, or is there a way to have it honor the authentication of the identity by another source?

    – Or is there a simpler way to handle the interface at the business layer?

    #4527
     Rogerio Rondini
    Participant

    Hi Gregory,

    It seems that you will need to customize de OpenAM Policy Schema to fit your fine-grained requirement. Also, you will need to use OpenAM REST API to query PDP.

    I think you can take a look at this chapter ..
    http://docs.forgerock.org/en/openam/12.0.0/dev-guide/index/chap-rest-authz-policy.html

    At

    #4533
     Gregory Wright
    Participant

    Rogerio,

    Thank you very much, that seems to confirm for me that we’ll need to pass through the authentication token of the requesting user.

    Kind regards,
    Greg

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