[ 
https://issues.apache.org/jira/browse/CXF-5118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14082221#comment-14082221
 ] 

Sergey Beryozkin edited comment on CXF-5118 at 8/1/14 1:21 PM:
---------------------------------------------------------------

Modifying every LoginModule which may be used can be tricky.

How about this. JAASLoginInterceptor has this line:

{code:java}
AuthorizationPolicy policy = message.get(AuthorizationPolicy.class)
{code} 

instead we'd have:

{code:java}
AuthorizationPolicy policy = getAuthorizationPolicy(message);
//...

protected AuthorizationPolicy getAuthorizationPolicy(Message m) {
    AuthorizationPolicy policy = message.get(AuthorizationPolicy.class);
    if (policy == null) {
         // 1. check the certificate
         // 2. if cert is available then check a mapper via the contextual 
property:
        CertificateMapper mapper = 
(CertificateMapper)m.getContextualProperty(CertificateMapper.class.getName());
        if (mapper != null) {
            policy = mapper.getAuthorizationPolicy(thecertificateInfo);
        }
    }
    return policy;
}
{code} 

So we'd have a CertificateMapper interface introduced, if we have a certificate 
available and the mapper registered then we'd do the mapping and proceed as 
usual.

Does it work ? IMHO it is probably yes..


was (Author: sergey_beryozkin):
Modifying every LoginModule which may be used can be tricky.

How about this. JAASLoginInterceptor has this line:

{code:java}
AuthorizationPolicy policy = message.get(AuthorizationPolicy.class)
{code} 

instead we'd have:

{code:java}
AuthorizationPolicy policy = getAuthorizationPolicy(message);
//...

protected AuthorizationPolicy getAuthorizationPolicy(Message m) {
    AuthorizationPolicy policy = message.get(AuthorizationPolicy.class);
    if (policy != null) {
         // 1. check the certificate
         // 2. if cert is available then check a mapper via the contextual 
property:
        CertificateMapper mapper = 
(CertificateMapper)m.getContextualProperty(CertificateMapper.class.getName());
        if (mapper != null) {
            policy = mapper.getAuthorizationPolicy(thecertificateInfo);
        }
    }
    return policy;
}
{code} 

So we'd have a CertificateMapper interface introduced, if we have a certificate 
available and the mapper registered then we'd do the mapping and proceed as 
usual.

Does it work ? IMHO it is probably yes..

> 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)

Reply via email to