You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by forda <da...@bredband.net> on 2009/12/01 08:35:44 UTC
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-propagating-username-in-same-call-tp26587711p26587711.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: SSL with mutual authentication for system and propagating
username in same call
Posted by forda <da...@bredband.net>.
Hi Eamon !
Thanks, and i agree. Been working with other tasks for a while now.
The orderer are very stubborn about using two-ssl, they do not even
care about the adminstration i think. A temporary solution is not always
the best, but the customer rules. If they are satified i am satisfied with
the solution even if i don't like it. Though i agree totally on that
temporary
solutions tend to be permanent. Cause no one cares if it is working,
does'nt
matter how bad it is.
Regarding your solution purposal, it is the right way to do it, and it's
easy to accomplish.
I will have that in mind while implementening the solution. The CXF client
still need to use
HttpConduit to pass the clientcertificate to the service, which is also part
of the
solution.
Regards,
Daniel
Eamonn Dwyer-2 wrote:
>
>
> 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: daniel.forberg@bredband.net
>> To: users@cxf.apache.org
>> 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:daniel.forberg@bredband.net]
>> > Sent: Tuesday, December 01, 2009 2:36 AM
>> > To: users@cxf.apache.org
>> > 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
>
Quoted from:
http://old.nabble.com/SSL-with-mutual-authentication-for-system-and-propagating-username-in-same-call-tp26587711p26630790.html
--
View this message in context: http://old.nabble.com/SSL-with-mutual-authentication-for-system-and-propagating-username-in-same-call-tp26587711p26695557.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: SSL with mutual authentication for system and propagating
username in same call
Posted by Eamonn Dwyer <ea...@hotmail.com>.
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: daniel.forberg@bredband.net
> To: users@cxf.apache.org
> 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:daniel.forberg@bredband.net]
> > Sent: Tuesday, December 01, 2009 2:36 AM
> > To: users@cxf.apache.org
> > 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
RE: SSL with mutual authentication for system and propagating
username in same call
Posted by forda <da...@bredband.net>.
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:daniel.forberg@bredband.net]
> Sent: Tuesday, December 01, 2009 2:36 AM
> To: users@cxf.apache.org
> 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.
RE: SSL with mutual authentication for system and propagating username in same call
Posted by Nate Woody <na...@cac.cornell.edu>.
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:daniel.forberg@bredband.net]
Sent: Tuesday, December 01, 2009 2:36 AM
To: users@cxf.apache.org
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.