Hi

SimpleAuthorizingInterceptor will only be effective if the current security context has been set up and I think it can understand yet the 2-way TLS info which WSS4JInInterceptor sets in.

What you can try to do is to extend SimpleAuthorizingInterceptor#handleMessage and attempt to convert the TLS info into the one understood by SimpleAuthorizingInterceptor

HTH, Sergey
On 30/08/12 19:31, Mickael Marrache wrote:
Here's my Spring context:

<beans xmlns="http://www.springframework.org/schema/beans";
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
xmlns:jaxws="http://cxf.apache.org/jaxws";
        xmlns:context="http://www.springframework.org/schema/context"; 
xmlns:util="http://www.springframework.org/schema/util";
        xsi:schemaLocation="http://www.springframework.org/schema/beans 
http://www.springframework.org/schema/beans/spring-beans.xsd
         http://www.springframework.org/schema/context 
http://www.springframework.org/schema/context/spring-context.xsd
        http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd
        http://www.springframework.org/schema/util 
http://www.springframework.org/schema/util/spring-util.xsd";>

        <import resource="classpath:META-INF/cxf/cxf.xml" />
        <import resource="classpath:META-INF/cxf/cxf-servlet.xml" />

        <jaxws:endpoint id="configService"
                implementor="com.mycompany.server.MyServiceImpl" 
address="/MyService">
                <jaxws:inInterceptors>
                        <bean 
class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor">
                                <constructor-arg>
                                        <map>
                                                <entry key="action" value="Timestamp 
Signature Encrypt" />
                                                <entry key="signaturePropFile" 
value="server-crypto.properties" />
                                                <entry key="decryptionPropFile" 
value="server-crypto.properties" />
                                                <entry 
key="passwordCallbackClass"
                                                        
value="com.mycompany.server.security.ServerPasswordCallback" />
                                        </map>
                                </constructor-arg>
                        </bean>
                        <bean
                                
class="org.apache.cxf.interceptor.security.SimpleAuthorizingInterceptor">
                                <property name="methodRolesMap" 
ref="methodRolesMap" />
                                <property name="userRolesMap" ref="userRolesMap" 
/>
                        </bean>
                </jaxws:inInterceptors>
                <jaxws:outInterceptors>
                        <bean 
class="org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor">
                                <constructor-arg>
                                        <map>
                                                <entry key="action" value="Timestamp 
Signature Encrypt" />
                                                <entry key="user" value="Server" 
/>
                                                <entry key="signaturePropFile" 
value="server-crypto.properties" />
                                                <entry key="encryptionPropFile" 
value="server-crypto.properties" />
                                                <entry key="encryptionUser" 
value="useReqSigCert" />
                                                <entry 
key="passwordCallbackClass"
                                                        
value="com.mycompany.server.security.ServerPasswordCallback" />
                                                <entry key="signatureParts"
                                                        
value="{Element}{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp;{Element}{http://schemas.xmlsoap.org/soap/envelope/}Body";
 />
                                                <entry key="encryptionParts"
                                                        
value="{Element}{http://www.w3.org/2000/09/xmldsig#}Signature;{Content}{http://schemas.xmlsoap.org/soap/envelope/}Body";
 />
                                                <entry key="encryptionSymAlgorithm" 
value="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"; />
                                        </map>
                                </constructor-arg>
                        </bean>
                </jaxws:outInterceptors>
        </jaxws:endpoint>

        <util:map id="methodRolesMap">
                <entry key="methodA" value="ROLE_CLIENT" />
                <entry key="methodB" value="ROLE_ADMIN" />
        </util:map>

        <util:map id="userRolesMap">
                <entry key="client" value="ROLE_CLIENT" />
                <entry key="admin" value="ROLE_ADMIN" />
        </util:map>
</beans>

After authentication takes place using the WSS4JInInterceptor, the 
handleMessage method of SimpleAuthorizingInterceptor is invoked. I don't 
understand why this configuration doesn't work. After authentication is done, 
we know who is the caller according the the information present in its 
certificate. Then, I would expect the userRolesMap to be used, so that we can 
know what is(are) the role(s) associated to this caller. And then, according to 
these caller's associated roles and the invoked method's associated role, we 
are able to say that the caller is authorized or not. I don't understand what 
SAML comes to solve here. Also, I still don't understand what is the meaning of 
sending my role(s) as a caller, this is something that should be determined by 
the server.


-----Message d'origine-----
De : Andrei Shakirin [mailto:[email protected]]
Envoyé : jeudi 30 août 2012 17:19
À : [email protected]
Objet : RE: Authorization with CXF and WSS4J?

Hi Mickael,

I know that I'm missing something here related to the TAG_SAML_ASSERTION. Maybe 
the caller has to provide its role inside the SOAP message? If
yes, I don't understand why, the caller should only know its identity, the 
roles is more for the server side which checks if the caller's identity is
associated to an expected roles.

Yep, correct.
SAML has extensions mechanism, where it is possible to define additional 
attribute statements.
In some scenarios it is really the case that STS service not only authenticate 
the user and issues SAML token with Authentication statement, but also maps 
user to role and inserts role as attribute statement in SAML. STS service has 
appropriate claims/attribute statements extensions points to do it (see as 
sample 
http://svn.apache.org/repos/asf/cxf/trunk/services/sts/sts-core/src/test/java/org/apache/cxf/sts/common/CustomClaimsHandler.java
 ).
Therefore WSS4JInInterceptors tries to get roles from the SAML.

You can follow this approach and extend STS to do user ->  roles mapping.
Other option is to do it in own interceptor. As basis you can look 
JAASLoginInterceptor and RolePrefixedSecurityContextImpl that just adds ROLE_ 
prefix to user name and interprets it as role 
(http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/cxf/interceptor/security/JAASLoginInterceptor.java
 ).

Regards,
Andrei.


-----Original Message-----
From: Mickael Marrache [mailto:[email protected]]
Sent: Donnerstag, 30. August 2012 13:26
To: [email protected]
Subject: RE: Authorization with CXF and WSS4J?

Hi Andrei,

Thanks for your helpful answer.

I'm trying to use the Interceptors provided by CXF but I get the following 
issue:

In the WSS4JInInterceptor, when the method doResults is called to construct the 
security result, at line 482, the condition 
o.get(WSSecurityEngineResult.TAG_SAML_ASSERTION) != null is false for me, so 
the createSecurityContext method is called without the roles (which causes to 
call createSecurityContext with null roles). So, when sc.isUserInRole(role) is 
called in AbstractAuthorizingInterceptor at line 100, it always returns false, 
so the call to isUserInRole(sc, expectedRoles, false) in 
AbstractAuthorizingInterceptor at line 84 also returns false, and the client is 
then never authorized.

I know that I'm missing something here related to the TAG_SAML_ASSERTION. Maybe 
the caller has to provide its role inside the SOAP message? If yes, I don't 
understand why, the caller should only know its identity, the roles is more for 
the server side which checks if the caller's identity is associated to an 
expected roles.

Thanks,
Mickael

-----Original Message-----
From: Andrei Shakirin [mailto:[email protected]]
Sent: Wednesday, August 29, 2012 4:36 PM
To: [email protected]
Subject: RE: Authorization with CXF and WSS4J?

Hi Mickael,

You can use CXF AbstractAuthorizingInInterceptor and 
SimpleAuthorizingInInterceptor as basis:
http://svn.apache.org/viewvc/cxf/trunk/rt/core/src/main/java/org/apache/cxf/interceptor/security/AbstractAuthorizingInInterceptor.java
http://svn.apache.org/viewvc/cxf/trunk/rt/core/src/main/java/org/apache/cxf/interceptor/security/SimpleAuthorizingInterceptor.java

Idea is the following: SimpleAuthorizingInInterceptor is configured with 
methods-roles map. Interceptor validates does user in given role have 
permissions to accessing method.

There is the sample configuration in
http://svn.apache.org/viewvc/cxf/trunk/systests/jaxrs/src/test/resources/jaxrs_jaas_security/WEB-INF/beans.xml

It can be a good starting point for your task.

Regards,
Andrei.

-----Original Message-----
From: Mickael Marrache [mailto:[email protected]]
Sent: Mittwoch, 29. August 2012 10:39
To: [email protected]
Subject: Authorization with CXF and WSS4J?

Hi,

I'm looking for a way to implement web service authorization with CXF but I 
can't find anything on the CXF documentation, nor on the web. I would like to 
define roles, and to specify for each web method which roles are authorized...
I've looked at the different WS-* support in the doc, especially WS-Security, 
WS-SecurityPolicy and WS-Policy but I don't understand how these can be use for 
authorization.

Please, provide me some links in the case it is possible.

Thanks


--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com

Reply via email to