[
https://issues.apache.org/jira/browse/CXF-5118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14092835#comment-14092835
]
Steve Storck edited comment on CXF-5118 at 8/11/14 2:50 PM:
------------------------------------------------------------
In case it is relevant, I am definitely seeing a situation where there is a TLS
connection but the certificate array is null. This is how I am checking:
{code}
TLSSessionInfo sessionInfo = message.get(TLSSessionInfo.class);
if (sessionInfo != null) {
final Certificate[] certs = sessionInfo.getPeerCertificates();
if (certs != null && certs.length > 0) {
... do stuff here ...
} else {
LOG.warning("No client certificates found: certs=" + certs);
}
}
{code}
This results in the logger warning message that informs me that certs=null. Is
this a potential bug? Is there any way that I'm doing something wrong, or can
I do anything to troubleshoot further? I get the same error if I use the rest
client plugin in Firefox, or if I just hit the rest endpoint via the address
bar in the browser with the https address.
was (Author: steve973):
In case it is relevant, I am definitely seeing a situation where there is a TLS
connection but the certificate array is null. This is how I am checking:
{code}
TLSSessionInfo sessionInfo = message.get(TLSSessionInfo.class);
if (sessionInfo != null) {
final Certificate[] certs = sessionInfo.getPeerCertificates();
if (certs != null && certs.length > 0) {
... do stuff here ...
} else {
LOG.warning("No client certificates found: certs=" + certs);
}
{code}
This results in the logger warning message that informs me that certs=null. Is
this a potential bug? Is there any way that I'm doing something wrong, or can
I do anything to troubleshoot further? I get the same error if I use the rest
client plugin in Firefox, or if I just hit the rest endpoint via the address
bar in the browser with the https address.
> Create CXF interceptor which will use HTTPS client certificates to create
> JAAS SecurityContext
> -----------------------------------------------------------------------------------------------
>
> Key: CXF-5118
> URL: https://issues.apache.org/jira/browse/CXF-5118
> Project: CXF
> Issue Type: New Feature
> Components: Core
> Reporter: Sergey Beryozkin
> Assignee: Christian Schneider
>
> Use case:
> The user authenticates against the webservice using an X509 client
> certificate. In case of successful authentication the JAAS security context
> should be populated with a Subject that stores the user name and the roles of
> the user. This is necessary to support Authorization at a later stage.
> Design ideas
> The SSL transport will be configured to only accept certain client
> certificates. So we can assume that the interceptor does not have to do a
> real authentication. Instead it has to map from the subjectDN of the
> certificate to the user name and then lookup the roles of that user. Both
> then has to be stored in the subject's principles.
> The mapping could be done inside a JAASLoginModule or before. Inside will
> give the user more flexibility.
> The next step to retrieve the roles should be done in one of the standard
> JAASLoginModules as the source of the roles can be quite diverse. So for
> example the LdapLoginModule allows to retrieve the roles from Ldap. At the
> moment these modules require the password of the user though which is not
> available when doing a cert based auth.
> So I see two variants to retrieve the roles:
> 1. Change the loginmodules like the LDAP one to be configureable to use a
> fixed ldap user for the ldap connect and not require the user password. So
> the module would have two modes: a) normal authentication and group gathering
> b) use a fixed user to just retrieve roles for a given user
> 2. Store the user password somewhere (e.g. in the mapping file). In this case
> the existing LDAPLoginModule could be used but the user password would be
> openly in a text file
> 3. Create new LoginModules with the desired behaviour (fixed user and only
> lookup of roles)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
