Symantec Access Management

 View Only
  • 1.  Broadcom API Gateway Integration with Broadcom/CA SiteMinder 12.8

    Posted Sep 23, 2019 01:18 PM
    Goal: To reuse existing enterprise access policies @ SiteMinder with API Gateway and OAuth ToolKit which SiteMinder is integrated with Oracle WebLogic with JavaEE Declarative Security for the backend APIs.

    Issue: Before SiteMinder prior to 12.8, it seems there is no easy to associate JWT to SiteMinder SMSESSION.

    Assumption: With SiteMinder 12.8, we can associate JWT token to internal SMSESSION seamlessly. i.e. SiteMinder 12.8 can help to validate OAuth2 JWT token and generates an SMSESSION to allow access to protected resources with Broadcom API Gateway 9.3 or 9.4. Does anyone do that with WebLogic backend?

    Questions:
    • Is there a hard assumption that there must always be an username involved when the client first accesses to BroardBoard/CA API Gateway ?  If not username involved, how SiteMinder can  associate  a JWT token to the existing access policies or SMSESSION?
    • OAuth2 generates JWT at the API Gateway and using scopes to define what can be protected. The following documentation suggests that SiteMinder can base on a JWT, SiteMinder 12.8 can generate an SMSESSION to access the protected resource, how OAuth2 scopes vs SMSESSION related? Or there is no relationship at all?

    Thanks in advance for any reply.
    Louie

    https://docops.ca.com/ca-single-sign-on/12-8/en/configuring/policy-server-configuration/authentication-schemes/json-web-token-jwt-authentication-scheme/


    ------------------------------
    Enterprise Architect
    TwoCoins.ca Inc.
    ------------------------------


  • 2.  RE: Broadcom API Gateway Integration with Broadcom/CA SiteMinder 12.8

    Broadcom Employee
    Posted Oct 03, 2019 11:47 AM

    How is the WebLogic backend called by Gateway or are you using SSO ASA agent ?

    Link GW JSON WebToken for auth type for SSO Authentication, however it does not consider WebLogic 


    https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/layer7-api-management/api-gateway/9-4/JSON-Web-Token-Authentication-for-CA-SSO-Authentication.html




  • 3.  RE: Broadcom API Gateway Integration with Broadcom/CA SiteMinder 12.8

    Posted Oct 03, 2019 12:28 PM
    SSO ASA agent is used.

    The goal is to reuse existing enterprise authorization policy for basicAuth when JWT is supported. For SiteMinder and WebLogic, domains/groups/users are defined but there is no concept of token. For JWT world, there should be a way to translate JWT to SMSESSION for SiteMinder 12.8?

    ------------------------------
    Enterprise Architect
    TwoCoins.ca Inc.
    ------------------------------



  • 4.  RE: Broadcom API Gateway Integration with Broadcom/CA SiteMinder 12.8
    Best Answer

    Posted Oct 04, 2019 12:48 AM
    Q) Is there a hard assumption that there must always be an username involved when the client first accesses to BroardBoard/CA API Gateway ? If not username involved, how SiteMinder can associate a JWT token to the existing access policies or SMSESSION?

    A) Assuming you are talking about creating OAuth2 based on your second question, answer is yes.There has to be username with a identity provider in gateway or some form of external call you make to retrieve it. If you are only making Ca API gateway as client creating a regular JWT is also feasible with some username that you can pass to JWT Auth scheme in SiteMinder. I dont think JWT bearer OAuth grant is supported by SiteMinder.

    Q) OAuth2 generates JWT at the API Gateway and using scopes to define what can be protected. The following documentation suggests that SiteMinder can base on a JWT, SiteMinder 12.8 can generate an SMSESSION to access the protected resource, how OAuth2 scopes vs SMSESSION related? Or there is no relationship at all?

    A) JWT based Access Tokens vs regular JWT's are little different. There is not direct way for SiteMinder to leverage the JWT based access tokens with scopes,redirect_uri etc to make policy based decisions on resources being accessed, however all claims(including scopes) can be read to make authorization decisions while checking against something or simply pass them as headers for the app to make decision. Not sure how you are leveraging the weblogic ASA(only to verify identity from session or even using JAAS for authz as well) but the claims should help in architect'ing the solution.

    hope this helps.