AuthAz WebServices.

[Vivek_S]

Hi i am trying to test AuthAZ webservices , i have been able to make it work with basic auth scheme, i am now trying to configure the Cert auth scheme.  I am confused as to does every user who access this webservice will need to present a certificate to access the webservice is that how it is supposed to work as in cert mapping it maps to the UID in a directory.

 

Can anyone help me understand how X509 cert auth scheme will work with this one ?

 

Thanks

[Patrick Dussault]

Hi Vivek,

 

To configure x509 Authentication Scheme certificate mapping to a UID, you have

to set the certificate IssuerDN and map it to a single attribute which will be

UID in your case.

 

in the Certificate Mapping Properties :

 

Issuer DN : DC=com,DC=training,DC=root,CN=My CA Certificate Authority

 

Mapping :

 

Single Attribute

Attribute Name : UID (User ID)

 

If the UID is in the User Store, you might set a Custom Mapping Expression :

 

UserAttribute=%{CertificateAttribute}

 

Where the CertificateAttribute will have the value of the UID (user attribute)

 

What have you tried as configuration ?

 

ref.:

 

https://docops.ca.com/ca-single-sign-on-12-52-sp1/en/configuring/policy-server-configuration/certificate-mapping-for-x-509-client-certificate-authentication-schemes

 

https://docops.ca.com/ca-single-sign-on-12-52-sp1/en/configuring/ca-siteminder-sps-configuration/configuring-the-authentication-and-authorization-web-services

 

Best Regards,

Patrick

[Vivek_S]

HI Patrick,

 

Thanks for the info on cert auth scheme , i know how the X509 scheme works, my question was more on the requirement of having X509 scheme to protect the webservices, i want to understand that every user who access the webservices will then get authenticated with cert implying every user will need a cert . For SOAP webservice you need to send username/password in a SOAP request then in case of cert scheme how would my SOAP request look like ?.

 

Thanks

[Mark ODonohue]

Hi Vivek

 

Here is a related answer, it is a confusing area, and re-reading my original response here - I think I will re-visit it and try clarify it again :

https://communities.ca.com/message/241890782#comment-241890782

 

For "RequireAgentEnforcement=yes" It really depends what you are trying to do with the webservice,

 

If you intent is :

• a) If you use is for an app on a mobile from any users phone. eg:
      <client>- -> <sps webservice>
       <client> --> <some SM protected resource>
  Then presumably you want the client to directly call the SPS webservice passing UN/PW and get back an smToken, which you can then use as an SMSESSION cookie to access a normal SM protected resource.
  
  In this case you dont really need authentication to access the SPS webservice, as you want every user to have access and be able to call it.  Or if any then you could have some basic auth password hardcoded in your app - but its only cursory as essentially you want to site accessable by non-logged on people.
  
  
• b) If  your use is as a backend service
  And you want  to Logon users and  verify their access before giving them the resource eg:
       <client> --> <yourwebservice> --> <your backend server>
  where yourwebservice does the login /az by talking to the sps webservice :
       <yourwebservice> ---> <sps webservice>
  And on yourwebservice you dont want to install a webagent, but do have the ability to call webservies call on SPS so that you can make login/Az calls on behalf of the client from youwebservce.  And based on those you set an SMSESSION cookie for them, and (if Az passes) give them access to the backend resource.
  
  Now in this case, you do want "RequireAgentEnforcement=yes" because only <yourwebservice> should have access to the <sps webservice> and everyone else should not be allowed.   So in this case you want your <yourwebservice> to connect to the <sps webservice> provide some authentication (basic or client certificate) and only then can it make webservice calls on behalf of the <client>.  The <client> in this case does not have direct access to the <sps webservice>.
  

So for case 2) it is a bit weird, since to access the <sps webservice> to log someone on, you need to already have an SMSESSION cookie - but that is the intent.  I suspect the design of the feature really is for case 2) setup. 

 

For case 1) style usage, the call to the Login makes sense to get an SMSESSION cooke.  But for Az call from a module app does not make sense - cause you want to call a server that can give you the resource, not a service that just tells you a YES/NO if you have access to the resource. 

Hope that helps.

Cheers - Mark