Подход состоит в том, чтобы иметь два отдельных ограничения безопасности , даже если у общедоступной службы нет никаких ограничений вообще (ни auth-constraint
, ни user-data-constraint
).Предполагается, что две службы имеют разные URL-адреса, что, скорее всего, имеет место:
<security-role>
<role-name>ProtectedServiceRole</role-name>
</security-role>
<security-constraint>
<web-resource-collection>
<web-resource-name>Public Service</web-resource-name>
<url-pattern>/PublicService/*</url-pattern>
</web-resource-collection>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>Protected Service</web-resource-name>
<url-pattern>/ProtectedService/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
<auth-constraint>
<role-name>ProtectedServiceRole</role-name>
</auth-constraint>
</security-constraint>
Имя роли, указанное в auth-constraint
, инициирует аутентификацию.
Обновление:
Боюсь, я неправильно прочитал ваш вопрос и пропустил часть проверки подлинности сертификата.Несмотря на то, что я использовал его в прошлом, у меня никогда не было смешанной настройки, которая вам нужна, поэтому я могу дать только некоторые варианты, которые вы можете попробовать затем:
В настоящее время вам требуется аутентификация на транспортном уровне.Это на низком уровне и слишком рано.Вы пробовали установить clientAuth в false и вместо этого добавить следующие строки в ваш web.xml:
<login-config>
<auth-method>CLIENT-CERT</auth-method>
</login-config>
Другой подход заключается в использовании двух разных портов длядве услуги.Для этого вы определяете два разных соединителя в файле server.xml.