cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Piotr Klimczak (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CXF-5118) Create CXF interceptor which will use HTTPS client certificates to create JAAS SecurityContext
Date Thu, 07 Aug 2014 14:58:13 GMT

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

Mime
View raw message