EJBCA web service (WSDL) is accessible without client authentication

[merryo11]

I am using ejbca 8 with docker and tried to access web service on port 443 and got the WSDL without any client authentication so my question is if this is a normal behavior to get the WSDL or am I missing something.

Secondly, once I step into the RA operations like searching and creating the entities or generating the certificates then I must use the RA certificate to make my web service work otherwise it shall not work. Is my understanding correct or not.

[merryo11]

any update from the community

[svenska-primekey]

Once you deploy the container setup the roles and make sure the public access role is removed and that there is no public access token rule in the super admin role. Then see how the web services behave.

[merryo11]

Hi Sven, Yes I have a Public access token and by removing it the WSDL doesn't open without client authentication.

Now why I had this public access is because I want to let general users access enrollment link https://node1/ejbca/ra/enrollwithusername.xhtml to download their certificates rather giving them access through RA web which is not an option for us.

Can you further guide how can I achieve both the features i.e. access to web api with client authentication and also let general user enroll with public access role.

[primetomas]

For the first question. Yes, it is normal to be able to get the WSDL without client certificate authentication.

[merryo11]

So anyone who knows the web service link can easily consume it in the programming code and start creating entities and certificates. Don't you think it is dangerous.

[primetomas]

Reading the WSDL does not let you do any actual commands. The WSDL file is simply an XML file describing the API, that clients use to generate stub code on their side.
Or did you actually manage to make a WS call to add an end entity without authentication?

[svenska-primekey]

If the latter is the case, that is a role misconfiguration. Review the super admin role and any other rule to verify there are not Public Access Token permissions defined in members of the role.