Hi Daniel
I too would go down the route of using WSS to send the client's id. Using 2 way 
SSL mutual authentication, while possible, will prove to be a headache to 
maintain. Client certificate management/distribution is a real pain, and I know 
they say it's a temporary solution but from experience temporary solutions tend 
to take on a life of their own and become the permanent solution.

WSS over target only SSL authentication should not be that difficult to set up, 
there is probably enough examples/tests in the code base to get you started.

To answer your question below, your server can get the principal from the 
WebserviceContext using the following code.

@Resource
private WebServiceContext context;

 public java.lang.String greetMe(java.lang.String inparameter) {
        LOG.info("Executing operation greetMe");

        Principal p = context.getUserPrincipal();
        if (p != null) {
            System.out.println("p.getName() = " + p.getName());
        }        
        return new java.lang.String("Hi " + inparameter);
    }

But rather than have this principal extraction in the server code it may be 
better to create an interceptor to do the authorization for you. That way you 
could more easily apply it to/remove it from other endpoints you created, 
through the use of spring config.

And maybe even push the envelope a bit further and use WS-Security policy to 
ensure that the policy is applied properly. You could have a policy like the 
one below and apply it to you endpoint or even binding


Hope this helps 
Eamonn

<wsp:Policy wsu:Id="UP_policy">
     <wsp:ExactlyOne>
       <wsp:All>    
        <sp:TransportBinding 
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>
          <wsp:Policy>
            <sp:TransportToken>
              <wsp:Policy>
                <sp:HttpsToken RequireClientCertificate="false" />
              </wsp:Policy>
            </sp:TransportToken>
            <sp:Layout>
              <wsp:Policy>
                <sp:Strict/>
              </wsp:Policy>
            </sp:Layout>
            <sp:AlgorithmSuite>
              <wsp:Policy>
                <sp:Basic128/>
              </wsp:Policy>
            </sp:AlgorithmSuite>
            <sp:IncludeTimestamp/>
          </wsp:Policy>
        </sp:TransportBinding>
        <sp:SignedSupportingTokens 
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>
          <wsp:Policy>
            <sp:UsernameToken 
sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Always";>
              <wsp:Policy>
                <sp:WssUsernameToken10/>
              </wsp:Policy>    
            </sp:UsernameToken>
          </wsp:Policy>
        </sp:SignedSupportingTokens>
            </wsp:All>
        </wsp:ExactlyOne>        
    </wsp:Policy> 



> Date: Tue, 1 Dec 2009 06:51:35 -0800
> From: [email protected]
> To: [email protected]
> Subject: RE: SSL with mutual authentication for system and propagating 
> username in same call
> 
> 
> Hi !
> 
> Nate, thanks for your feeback.
> I have the same opinion regarding two-ssl, and presented a full solution
> a while ago. But seems the customer wanted a temporary solution based
> on two-way ssl instead. My task is to document how to do so they can compare
> the different solutions.
> 
> The full solution is based on WSS and SAML, hence not implemented yet.
> 
> Regards,
> 
> Daniel
> 
> 
> Nate Woody-2 wrote:
> > 
> > Hello,
> > 
> > I, too, am interested in intelligent ways to implement this solution and
> > so am interested in any feedback on this.  We recently implemented
> > something similar and I've got an axe to grind. 2-way SSL is a bit of an
> > annoyance as it's really out-of-band with the web service.  CXF has
> > essentially no role to play (aside from the fact that I configured 2-way
> > ssl in cxf.xml), so the certificates used for client authentication must
> > be separately accessed if you want to include something from that in the
> > message.  In our case, we were able to extract the DN from the client
> > SSL certificate on the server side and then do a look-up with that DN
> > for authorization of the particular action.  But that's a mess.
> > Depending on how requirement-y your requirements are, it feels like a
> > better solution is to use 1-way SSL to secure the channel and then use
> > WSS to identify the individual call inside the ssl connection.  This has
> > the advantage of putting all authentication and authorization inside the
> > message and relying on SSL only to secure the transport channel. It
> > should probably be noted that these are all essentially in pursuit of a
> > stateless solution where every message is individually authorized, as
> > opposed to a solution that implements some sort of a login (which is how
> > I used to operate in the XFire world).
> > 
> > Given all that, I'd be interested in hearing the opinion of someone who
> > knows what they're talking about.
> > 
> > Best,
> > Nate
> > 
> > -----Original Message-----
> > From: forda [mailto:[email protected]] 
> > Sent: Tuesday, December 01, 2009 2:36 AM
> > To: [email protected]
> > Subject: SSL with mutual authentication for system and propagating
> > username in same call
> > 
> > 
> > Hi !
> > 
> > I am designing a security solution ordered from the Security architect
> > for a
> > customer i work for.
> > The requirement is to use a two-way ssl handshake in order
> > indentify/authenticate system access
> > to webservices. Except the authentication of the system against CA
> > Certificate, authorization map is needed to determine which systems have
> > access to which services. 
> > 
> > The systems enduser must also be propagated in the call for auditing
> > logging
> > purposes.
> > 
> > The infrastructure used is Apache webbserver 2.2.X, Tomcat 6, Private CA
> > and
> > CXF 2.2.4 of course.
> > In order to make this to work there are a number of options to
> > accomplish
> > the same thing.
> > Therefore i just want to discuss the solution with you here at the
> > forum, to
> > achieve the other
> > opions and knowledge than my own.
> > 
> > *Certificates generated by private CA
> > *HTTPConduit can be used to establish the two-way ssl handshake with use
> > of
> > client-certificate used in conjunction with jaxws-client. Is there a way
> > to
> > add the system identity to the Principal object along with the username
> > which indentifies the user ? One option would be to use X509 Token
> > Profile
> > or CLIENT-CERT authentication or ?
> > *Customized authorization based on client-certificates subject dn, map
> > against the service/-es. ? Any built in support for this?
> > *WSS Security, wit WSS4j to accomplish propagation if the username, no
> > need
> > for authentication, though include the username in the Principal in the
> > webservicecontext. Does the WSS4J interceptor put the username in the
> > Principal object on the Webservicecontext which is injected with
> > @Resource
> > annotation ? If not, howto ?
> > 
> > Thanks in advance.
> > 
> > Regards,
> > 
> > Daniel
> > 
> > 
> > 
> > -- 
> > View this message in context:
> > http://old.nabble.com/SSL-with-mutual-authentication-for-system-and-prop
> > agating-username-in-same-call-tp26587711p26587711.html
> > Sent from the cxf-user mailing list archive at Nabble.com.
> > 
> > 
> > 
> 
> -- 
> View this message in context: 
> http://old.nabble.com/SSL-with-mutual-authentication-for-system-and-propagating-username-in-same-call-tp26587711p26593094.html
> Sent from the cxf-user mailing list archive at Nabble.com.
> 
                                          
_________________________________________________________________
New Windows 7: Find the right PC for you. Learn more.
http://windows.microsoft.com/shop

Reply via email to