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