Symantec Access Management

 View Only
  • 1.  12.7 - OpenID Connect Configuration for cert auth?

    Posted May 12, 2017 11:24 AM

    Just curious if anyone has done it yet, or if someone from CA has some input, for doing client-cert auth to the OIDC endpoints. And if that'd be considered a supportable configuration or not.


    Basically instead of relying on the bearer access token alone to say the userinfo endpoint, require the added layer of requiring a certificate from a valid trusted issuer.


    As a whole, we want to avoid passing any detailed user information based on a bearer token alone, so having the layer of having to be a valid issued cert would allow greater security there; to compromise the user info would have to gain access to not only the access token alone but also specific client cert.


    Since the AG has Apache as the proxy, figured it should be doable in the configs? 

  • 2.  Re: 12.7 - OpenID Connect Configuration for cert auth?

    Posted Jun 05, 2017 08:00 AM

    This implementation would be dependent on the Relying party side of the federation.  if SSO is generating the OIDC token, then SSO really has no control over what is being done at the RP side.  If SSO is on both the OP and the RP side, then I would suggest the gateway alnog with a SSO session that can be validated at the gateway.


    Another approach is to insert the SSO token into the OIDC token.  Then to have the RP call the SSO REST service to validate the SSO token in the OIDC token is valid.  

  • 3.  Re: 12.7 - OpenID Connect Configuration for cert auth?

    Posted Jun 09, 2017 03:38 PM

    I'm not following how that would address the concern here?


    CA Access Gateway is controlling the user info and token exchange endpoints. So it's reliant on (1) CA Access Gateway being able to require a layer in addition to just a bearer token [all it needs oob is the access token], and (2) the client app/RP to have a valid issued client-auth certificate [with appropriate policy OIDs].


    Layering a bearer token on top of another bearer token (i.e., SMSESSION + OIDC) is still all bearer tokens with no specific verification of the calling client. So the concern around passing back higher rated user information by simply having that token is still not addressed; especially when considering exposing it externally. Also the userinfo endpoint just needs the access_token, don't think it knows anything about SMSESSION.


    Intention here would be that a compromised OIDC access_token would not provide any specific access to the userinfo endpoint on the CA Access Gateway. Since if TLS client-cert auth is required, to compromise that they'd have to get hold of the private key (which could be stored in an HSM etc) in addition to the bearer token; either one by itself would do no good.


    Overall the goal, for us at least, is to lock down as much authentication as possible to client-cert auth (or at minimum short-lived PKI cert signed requests). That includes touch points to APIs, users to authentication services, etc.


    At the very least if I could require the UserInfo endpoint to need both the (1) access_token granted by the user and (2) client id + client secret, that would probably be adequate enough. Based on the documentation, I didn't see that even this was possible and the currently accepts just the access_token. Having only the access_token doesn't authenticate the client sending it.