[
https://issues.apache.org/jira/browse/CXF-5118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14089297#comment-14089297
]
Piotr Klimczak commented on CXF-5118:
-------------------------------------
I think that the perfect solution we are looking for is:
0. Simple
0. Clean
0. Descriptive
0. Secure
1. Provides ability to reauthenticate to get roles from JAAS Module without
password, then let the further work be done in security context
2. Provides ability to reauthenticate to get roles from JAAS Module using
technical password, then let the further work be done in security context
3. Provides ability to reauthenticate to get roles from JAAS Module using user
mapped password, then let the further work be done in security context
4. Provides ability to getroles from somewhere, to bypass invoking JAAS Login
modue, then let the further work be done in security context
5. Provides ability to chose which credentials/authentication method is more
important (if more than one supplied, which is easy to imagine), then let the
further work be done in security context
Question here: Am I missing some required functionality?
If yes, then please add them to the list (kind of check list).
All zeros ("0.") are most important, but also subjective so probably there will
be always small differences here between us.
But those 1. to 5. are simply functional requrements which are simply provided
by our solution or not.
*IN REFERENCE TO:*
https://github.com/cschneider/cxf/commit/bc436011e99084b5e2f1165b70aa4cf028a49a1a
With this solution requirements 1. to 3. it will work perfectly.
There are gaps for requirements 4. and 5.
Also number of introduced types is increasing.
Solving functional gaps will probably make JAASLoginInterceptor even more
complex and possibly even more types will be introduced OR simply we will give
up with implementing them.
(I am terribly sorry for punctiations. I do really like your code, I do really
like you, I do agree with you in lot of places, but after 4 evaluations of
code, I simply think that JAASLoginModule should not do TLS stuff because of
increasing complexity).
*GAPS*
*Requirement 4* seems to not work at all.
Requirement 4. is very important for high secure environments. Take a look at
my example scenario here:
https://issues.apache.org/jira/browse/CXF-5118?focusedCommentId=14086222&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14086222
*Requirement 5* has security problem/limitation.
Simply because amending JAASLoginInterceptor to do TLS stuff instead of
creating new interceptor. That is because one JAASLoginInterceptor can use only
one JAAS context (Login Module) at same time.
So if you want to use let's say JAAS context (Login Module) that works with
technical password for all users, then it will not let you work with user
specified password in parallel.
Scenario for this is as follow:
Let's say there is an application that let the user to login using
login/password or private key/certificate and it is up to user which he chose.
So in this scenario technical certificate might be used just to setup mutually
trusted connection and then user supplied credentials could be used to find
user roles from JAAS Login module. In parallel very same service is used to
authenticate users using personal certificate only.
The above scenario will only work with separate interceptor unless we want to
change JAASLoginModule to support 2 different Login Module in parallel but I do
not think so.
*IN REFERENCE TO*:
https://github.com/PiotrKlimczak/cxf/commit/683c575f451406bd304640e3973aecb9a1651acc
Will work for requirements 1. to 4.
*GAPS*
*Requirement 5* will work with 50% scenarios.
If user will use just TLSAuthenticationInterceptor WITH OUT
JAASLoginInterceptor, then user will be able to decide as have to write login
logic.
But if user will decide to use TLSAuthenticationInterceptor altogether with
JAASLoginInterceptor, then will not be able to figure out which authentication
is more important. Simply when TLS Auth is done and user additionally will
provide HTTP Authentication credentials, then those from HTTP Auth will be
considered to be more important, overwriting security context created by
TLSAuthenticationInterceptor.
But as an advantage would be that user can use two different JAAS Login Modules.
*Additionally:*
The problem is, that once we decide to amend JAASLoginInterceptor to handle
certificates, it will be difficult to make it a separate interceptor in future.
Simply because it will be incompatible change. So once we decide to amend
JAASLoginInterceptor, we will problably stay with it. And we will always be
forced to look for compromises between complexity and functionality instead of
being free. Unless we want to force our users to do some kind of migration from
JAASLoginInterceptor to new one somewhere in the future.
Please consider it when making a decision whether we should create new
Interceptor or reuse existing one.
Even if both of them have something to do with JAAS.
*Small update to code*
I also added some helper method to let the user do some JAAS login stuff easier.
Take a look at pull request in github.
So now user provided implementation for tech password od password less
authentication in JAAS (if user need this) may look like this:
{code}
public class MySecuritySubjectProvider extends TLSSecuritySubjectProvider {
private String techPassword;
private String contextName;
@Override
Subject getSubject(String userName, X509Certificate certificate) throws
SecurityException {
CallbackHandler handler = new NamePasswordCallbackHandler(name,
techPassword);
return login(contextName, handler);
}
}
{code}
I can also add 2 additional properties to TLSAuthenticationInterceptor, like:
jaasLoginContextName
defaultPassword
And then change the default impl. of TLSSecuritySubjectProvider to handle them
and if provided to do JAAS reauthenticatioin stuff without forcing the user to
code anything.
But not sure about that.
Just in case you want to.
Please correct me where I am wrong.
Hope you find it well.
Sorry for such a long story here.
> 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)
