You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Iván Brencsics <iv...@gmail.com> on 2013/05/26 00:48:21 UTC
WS-Trust token handling
Hello,
I need to design a distributed software architecture that implements SSO
with WS-Trust/SAML. I have made some experiments, read the excellent blogs
of the Talend colleagues, and now I have an idea how WS-Trust is working.
I would just have three questions:
1) In my architecture, there are many components that call each other via
SOAP. The idea is that when the first component is triggered, it acquires a
SAML token from the STS, and then during the subsequent calls this single
token is used until the workflow is completed. So lets say 1) the module no
1 is triggered; 2) it acquires a SAML token; 3) calls module no 2; 4) when
module no 2 calls module no 3, the same SAML token is transmitted. Is this
possible with the CXF implementation?
2) I need to put claims in the token (eg roles). I saw in a blog how to do
that. But on the receiving side, what is the best way to evaluate the
claims found in the received token? For instance, how to retrieve the role
claims? Should I implement some interceptor for that?
3) I would prefer using SOAP over JMS. Is every WS-Trust operation working
over JMS the same way as over HTTP?
Thank you in advance.
Kind regards,
Ivan
Re: WS-Trust token handling
Posted by Iván Brencsics <iv...@gmail.com>.
Hi Oliver again,
Sorry for spamming you. I have no idea what I did, but the 1.1.0-SNAPSHOT
RP(tomcat)/IDP/STS is working now. Please forget my previous two mails.
Kind regards,
Ivan
2013/6/4 Iván Brencsics <iv...@gmail.com>
> Hi Oliver,
>
> I found an error in my URL:
> https://localhost:9443/fediz-idp/federation*/*
> ?wa=wsignin1.0&wreply=https%3A%2F%2Flocalhost%3A8443%2Ffedizhelloworld%2Fsecureservlet%2Ffed&wtrealm=https%3A%2F%2Flocalhost%3A8443%2Ffedizhelloworld%2F
>
> I had to get rig of the "/" after "federation". But anyway, I dont get
> redirected, but get back an HTML page saying "CXF Fediz IDP successully
> logout". The same happens when I run the simpleWebApp.
>
> Regards,
> Ivan
>
>
>
>
> 2013/6/4 Iván Brencsics <iv...@gmail.com>
>
>> Hi Oliver,
>>
>> Thanks, the tomcat-idp.jks was the keystore I was looking for.
>>
>> However, I cannot make the 1.1.0-SNAPSHOT IDP running. I am using the
>> same Tomcat as for 1.0.0, I only replace the keystore for the HTTPS
>> connector.
>>
>> I simply deploy the STS and IDP. The STS WSDL is available as always. But
>> when I access the IDP, nothing happens.
>>
>> I put this in a browser:
>>
>> https://localhost:9443/fediz-idp/federation/?wa=wsignin1.0&wreply=https%3A%2F%2Flocalhost%3A8443%2Ffedizhelloworld%2Fsecureservlet%2Ffed&wtrealm=https%3A%2F%2Flocalhost%3A8443%2Ffedizhelloworld%2F
>>
>> In the Tomcat console I see this:
>>
>> ---
>>
>> ************************************************************
>>
>> Request received for
>> '/federation/?wa=wsignin1.0&wreply=https%3A%2F%2Flocalhost%3A8443%2Ffedizhelloworld%2Fsecureservlet
>> %2Ffed&wtrealm=https%3A%2F%2Flocalhost%3A8443%2Ffedizhelloworld%2F':
>>
>> org.apache.catalina.connector.RequestFacade@559081
>>
>> servletPath:/federation/
>> pathInfo:null
>>
>> Security filter chain: [
>> STSPortFilter
>> SecurityContextPersistenceFilter
>> BasicAuthenticationFilter
>> RequestCacheAwareFilter
>> SecurityContextHolderAwareRequestFilter
>> AnonymousAuthenticationFilter
>> SessionManagementFilter
>> ExceptionTranslationFilter
>> FilterSecurityInterceptor
>> ]
>>
>>
>> ************************************************************
>>
>>
>> Jun 04, 2013 10:33:09 AM org.apache.cxf.fediz.service.idp.STSPortFilter
>> doFilter
>> INFO: STSAuthenticationProvider.wsdlLocation set to
>> https://localhost:9443/fediz-idp-sts/STSService?wsdl
>>
>> ---
>>
>>
>> But the request is not redirected, and I get back simply HTTP 404. In
>> case of 1.0.0 this was working, a SAML token was generated and the browser
>> was redirected. I am using the latest Fediz from github. Can you please let
>> me know, how this new release is working? I see that many things have
>> changed, now there is no IDPServlet, but Spring Security, and I am a bit
>> lost.
>>
>> And how do you expect, when do you release the 1.1.0 final?
>>
>> Kind regards,
>> Ivan
>>
>>
>>
>>
>>
>>
>>
>>
>> 2013/6/3 Oliver Wulff <ow...@talend.com>
>>
>>> Hi Ivan
>>>
>>> The IDP doesn't trust somebody. Instead, the application (relying party)
>>> trusts the IDP/STS. In this case, the signer is within the stsstore.jks:
>>>
>>> http://svn.apache.org/viewvc/cxf/fediz/trunk/services/sts/src/main/resources/stsstore.jks?view=log
>>> This certificate hasn't been changed.
>>>
>>> But maybe you mean the communication between the IDP and STS where the
>>> tomcat keystore of the STS must be in the certificate chain of the IDP to
>>> establish an SSL connection successfully.
>>>
>>> The following html page illustrates the usage of the different keys:
>>>
>>> http://svn.apache.org/viewvc/cxf/fediz/trunk/examples/samplekeys/HowToGenerateKeysREADME.html?view=co
>>>
>>> You must use the tomcat-idp.jks for the https settings in tomcat:
>>>
>>> http://svn.apache.org/viewvc/cxf/fediz/trunk/examples/samplekeys/tomcat-idp.jks?view=log
>>>
>>> HTH
>>>
>>> Oli
>>>
>>> ________________________________________
>>> From: Iván Brencsics [ivan.brencsics@gmail.com]
>>> Sent: 03 June 2013 12:24
>>> To: users@cxf.apache.org
>>> Subject: Re: WS-Trust token handling
>>>
>>> Hi Oliver,
>>>
>>> Thanks for your answers, all you recommened has been working. I followed
>>> your blogs, and managed to make running the STS, IDP, RP, and the web
>>> service client (with tomcat plugin). But only with the 1.0.0 version. In
>>> case of later Fediz releases there is problem with the tomcat keystore.
>>>
>>> * In 1.0.0 the tomcat keytstore has a key with the following cert:
>>> CN=localhost, SHA1: FE:B6.... The IDP has this cert in its truststore
>>> * In 1.1.0-SNAPSHOT the IDP trusts this cert: CN=localhost, SHA1:
>>> A6:BC...
>>>
>>> I know very well that I could generate the keys/keystores by myself, but
>>> first I would prefer running your examples as they are, as they come out
>>> from github. Could you please share with me the tomcat keystore you are
>>> using currently, that the current IDP trusts?
>>>
>>> Thank you very much, kind regards,
>>> Ivan
>>> +49 179 3814022
>>>
>>>
>>>
>>>
>>>
>>> 2013/5/27 Oliver Wulff <ow...@talend.com>
>>>
>>> > Hi
>>> >
>>> > 1) Yes, CXF supports caching the token per user dependent on AppliesTo
>>> and
>>> > Lifetime. So each component must have a different AppliesTo value.
>>> >
>>> > 2) This is supported. Just use the WebServiceContext API. Fixed here:
>>> > https://issues.apache.org/jira/browse/CXF-4212
>>> >
>>> > The following example uses this API:
>>> >
>>> >
>>> http://svn.apache.org/viewvc/cxf/fediz/trunk/examples/wsclientWebapp/webservice/
>>> >
>>> > 3) Never tested.
>>> >
>>> > Thanks
>>> > Oli
>>> >
>>> >
>>> > ------
>>> >
>>> > Oliver Wulff
>>> >
>>> > Blog: http://owulff.blogspot.com
>>> > Solution Architect
>>> > http://coders.talend.com
>>> >
>>> > Talend Application Integration Division http://www.talend.com
>>> >
>>> > ________________________________________
>>> > From: Iván Brencsics [ivan.brencsics@gmail.com]
>>> > Sent: 26 May 2013 00:48
>>> > To: users@cxf.apache.org
>>> > Subject: WS-Trust token handling
>>> >
>>> > Hello,
>>> >
>>> > I need to design a distributed software architecture that implements
>>> SSO
>>> > with WS-Trust/SAML. I have made some experiments, read the excellent
>>> blogs
>>> > of the Talend colleagues, and now I have an idea how WS-Trust is
>>> working.
>>> >
>>> > I would just have three questions:
>>> >
>>> > 1) In my architecture, there are many components that call each other
>>> via
>>> > SOAP. The idea is that when the first component is triggered, it
>>> acquires a
>>> > SAML token from the STS, and then during the subsequent calls this
>>> single
>>> > token is used until the workflow is completed. So lets say 1) the
>>> module no
>>> > 1 is triggered; 2) it acquires a SAML token; 3) calls module no 2; 4)
>>> when
>>> > module no 2 calls module no 3, the same SAML token is transmitted. Is
>>> this
>>> > possible with the CXF implementation?
>>> >
>>> > 2) I need to put claims in the token (eg roles). I saw in a blog how
>>> to do
>>> > that. But on the receiving side, what is the best way to evaluate the
>>> > claims found in the received token? For instance, how to retrieve the
>>> role
>>> > claims? Should I implement some interceptor for that?
>>> >
>>> > 3) I would prefer using SOAP over JMS. Is every WS-Trust operation
>>> working
>>> > over JMS the same way as over HTTP?
>>> >
>>> > Thank you in advance.
>>> >
>>> > Kind regards,
>>> > Ivan
>>> >
>>>
>>
>>
>
Re: WS-Trust token handling
Posted by Iván Brencsics <iv...@gmail.com>.
Hi Oliver,
I found an error in my URL:
https://localhost:9443/fediz-idp/federation*/*
?wa=wsignin1.0&wreply=https%3A%2F%2Flocalhost%3A8443%2Ffedizhelloworld%2Fsecureservlet%2Ffed&wtrealm=https%3A%2F%2Flocalhost%3A8443%2Ffedizhelloworld%2F
I had to get rig of the "/" after "federation". But anyway, I dont get
redirected, but get back an HTML page saying "CXF Fediz IDP successully
logout". The same happens when I run the simpleWebApp.
Regards,
Ivan
2013/6/4 Iván Brencsics <iv...@gmail.com>
> Hi Oliver,
>
> Thanks, the tomcat-idp.jks was the keystore I was looking for.
>
> However, I cannot make the 1.1.0-SNAPSHOT IDP running. I am using the same
> Tomcat as for 1.0.0, I only replace the keystore for the HTTPS connector.
>
> I simply deploy the STS and IDP. The STS WSDL is available as always. But
> when I access the IDP, nothing happens.
>
> I put this in a browser:
>
> https://localhost:9443/fediz-idp/federation/?wa=wsignin1.0&wreply=https%3A%2F%2Flocalhost%3A8443%2Ffedizhelloworld%2Fsecureservlet%2Ffed&wtrealm=https%3A%2F%2Flocalhost%3A8443%2Ffedizhelloworld%2F
>
> In the Tomcat console I see this:
>
> ---
>
> ************************************************************
>
> Request received for
> '/federation/?wa=wsignin1.0&wreply=https%3A%2F%2Flocalhost%3A8443%2Ffedizhelloworld%2Fsecureservlet
> %2Ffed&wtrealm=https%3A%2F%2Flocalhost%3A8443%2Ffedizhelloworld%2F':
>
> org.apache.catalina.connector.RequestFacade@559081
>
> servletPath:/federation/
> pathInfo:null
>
> Security filter chain: [
> STSPortFilter
> SecurityContextPersistenceFilter
> BasicAuthenticationFilter
> RequestCacheAwareFilter
> SecurityContextHolderAwareRequestFilter
> AnonymousAuthenticationFilter
> SessionManagementFilter
> ExceptionTranslationFilter
> FilterSecurityInterceptor
> ]
>
>
> ************************************************************
>
>
> Jun 04, 2013 10:33:09 AM org.apache.cxf.fediz.service.idp.STSPortFilter
> doFilter
> INFO: STSAuthenticationProvider.wsdlLocation set to
> https://localhost:9443/fediz-idp-sts/STSService?wsdl
>
> ---
>
>
> But the request is not redirected, and I get back simply HTTP 404. In case
> of 1.0.0 this was working, a SAML token was generated and the browser was
> redirected. I am using the latest Fediz from github. Can you please let me
> know, how this new release is working? I see that many things have changed,
> now there is no IDPServlet, but Spring Security, and I am a bit lost.
>
> And how do you expect, when do you release the 1.1.0 final?
>
> Kind regards,
> Ivan
>
>
>
>
>
>
>
>
> 2013/6/3 Oliver Wulff <ow...@talend.com>
>
>> Hi Ivan
>>
>> The IDP doesn't trust somebody. Instead, the application (relying party)
>> trusts the IDP/STS. In this case, the signer is within the stsstore.jks:
>>
>> http://svn.apache.org/viewvc/cxf/fediz/trunk/services/sts/src/main/resources/stsstore.jks?view=log
>> This certificate hasn't been changed.
>>
>> But maybe you mean the communication between the IDP and STS where the
>> tomcat keystore of the STS must be in the certificate chain of the IDP to
>> establish an SSL connection successfully.
>>
>> The following html page illustrates the usage of the different keys:
>>
>> http://svn.apache.org/viewvc/cxf/fediz/trunk/examples/samplekeys/HowToGenerateKeysREADME.html?view=co
>>
>> You must use the tomcat-idp.jks for the https settings in tomcat:
>>
>> http://svn.apache.org/viewvc/cxf/fediz/trunk/examples/samplekeys/tomcat-idp.jks?view=log
>>
>> HTH
>>
>> Oli
>>
>> ________________________________________
>> From: Iván Brencsics [ivan.brencsics@gmail.com]
>> Sent: 03 June 2013 12:24
>> To: users@cxf.apache.org
>> Subject: Re: WS-Trust token handling
>>
>> Hi Oliver,
>>
>> Thanks for your answers, all you recommened has been working. I followed
>> your blogs, and managed to make running the STS, IDP, RP, and the web
>> service client (with tomcat plugin). But only with the 1.0.0 version. In
>> case of later Fediz releases there is problem with the tomcat keystore.
>>
>> * In 1.0.0 the tomcat keytstore has a key with the following cert:
>> CN=localhost, SHA1: FE:B6.... The IDP has this cert in its truststore
>> * In 1.1.0-SNAPSHOT the IDP trusts this cert: CN=localhost, SHA1: A6:BC...
>>
>> I know very well that I could generate the keys/keystores by myself, but
>> first I would prefer running your examples as they are, as they come out
>> from github. Could you please share with me the tomcat keystore you are
>> using currently, that the current IDP trusts?
>>
>> Thank you very much, kind regards,
>> Ivan
>> +49 179 3814022
>>
>>
>>
>>
>>
>> 2013/5/27 Oliver Wulff <ow...@talend.com>
>>
>> > Hi
>> >
>> > 1) Yes, CXF supports caching the token per user dependent on AppliesTo
>> and
>> > Lifetime. So each component must have a different AppliesTo value.
>> >
>> > 2) This is supported. Just use the WebServiceContext API. Fixed here:
>> > https://issues.apache.org/jira/browse/CXF-4212
>> >
>> > The following example uses this API:
>> >
>> >
>> http://svn.apache.org/viewvc/cxf/fediz/trunk/examples/wsclientWebapp/webservice/
>> >
>> > 3) Never tested.
>> >
>> > Thanks
>> > Oli
>> >
>> >
>> > ------
>> >
>> > Oliver Wulff
>> >
>> > Blog: http://owulff.blogspot.com
>> > Solution Architect
>> > http://coders.talend.com
>> >
>> > Talend Application Integration Division http://www.talend.com
>> >
>> > ________________________________________
>> > From: Iván Brencsics [ivan.brencsics@gmail.com]
>> > Sent: 26 May 2013 00:48
>> > To: users@cxf.apache.org
>> > Subject: WS-Trust token handling
>> >
>> > Hello,
>> >
>> > I need to design a distributed software architecture that implements SSO
>> > with WS-Trust/SAML. I have made some experiments, read the excellent
>> blogs
>> > of the Talend colleagues, and now I have an idea how WS-Trust is
>> working.
>> >
>> > I would just have three questions:
>> >
>> > 1) In my architecture, there are many components that call each other
>> via
>> > SOAP. The idea is that when the first component is triggered, it
>> acquires a
>> > SAML token from the STS, and then during the subsequent calls this
>> single
>> > token is used until the workflow is completed. So lets say 1) the
>> module no
>> > 1 is triggered; 2) it acquires a SAML token; 3) calls module no 2; 4)
>> when
>> > module no 2 calls module no 3, the same SAML token is transmitted. Is
>> this
>> > possible with the CXF implementation?
>> >
>> > 2) I need to put claims in the token (eg roles). I saw in a blog how to
>> do
>> > that. But on the receiving side, what is the best way to evaluate the
>> > claims found in the received token? For instance, how to retrieve the
>> role
>> > claims? Should I implement some interceptor for that?
>> >
>> > 3) I would prefer using SOAP over JMS. Is every WS-Trust operation
>> working
>> > over JMS the same way as over HTTP?
>> >
>> > Thank you in advance.
>> >
>> > Kind regards,
>> > Ivan
>> >
>>
>
>
Re: WS-Trust token handling
Posted by Iván Brencsics <iv...@gmail.com>.
Hi Oliver,
Thanks, the tomcat-idp.jks was the keystore I was looking for.
However, I cannot make the 1.1.0-SNAPSHOT IDP running. I am using the same
Tomcat as for 1.0.0, I only replace the keystore for the HTTPS connector.
I simply deploy the STS and IDP. The STS WSDL is available as always. But
when I access the IDP, nothing happens.
I put this in a browser:
https://localhost:9443/fediz-idp/federation/?wa=wsignin1.0&wreply=https%3A%2F%2Flocalhost%3A8443%2Ffedizhelloworld%2Fsecureservlet%2Ffed&wtrealm=https%3A%2F%2Flocalhost%3A8443%2Ffedizhelloworld%2F
In the Tomcat console I see this:
---
************************************************************
Request received for
'/federation/?wa=wsignin1.0&wreply=https%3A%2F%2Flocalhost%3A8443%2Ffedizhelloworld%2Fsecureservlet
%2Ffed&wtrealm=https%3A%2F%2Flocalhost%3A8443%2Ffedizhelloworld%2F':
org.apache.catalina.connector.RequestFacade@559081
servletPath:/federation/
pathInfo:null
Security filter chain: [
STSPortFilter
SecurityContextPersistenceFilter
BasicAuthenticationFilter
RequestCacheAwareFilter
SecurityContextHolderAwareRequestFilter
AnonymousAuthenticationFilter
SessionManagementFilter
ExceptionTranslationFilter
FilterSecurityInterceptor
]
************************************************************
Jun 04, 2013 10:33:09 AM org.apache.cxf.fediz.service.idp.STSPortFilter
doFilter
INFO: STSAuthenticationProvider.wsdlLocation set to
https://localhost:9443/fediz-idp-sts/STSService?wsdl
---
But the request is not redirected, and I get back simply HTTP 404. In case
of 1.0.0 this was working, a SAML token was generated and the browser was
redirected. I am using the latest Fediz from github. Can you please let me
know, how this new release is working? I see that many things have changed,
now there is no IDPServlet, but Spring Security, and I am a bit lost.
And how do you expect, when do you release the 1.1.0 final?
Kind regards,
Ivan
2013/6/3 Oliver Wulff <ow...@talend.com>
> Hi Ivan
>
> The IDP doesn't trust somebody. Instead, the application (relying party)
> trusts the IDP/STS. In this case, the signer is within the stsstore.jks:
>
> http://svn.apache.org/viewvc/cxf/fediz/trunk/services/sts/src/main/resources/stsstore.jks?view=log
> This certificate hasn't been changed.
>
> But maybe you mean the communication between the IDP and STS where the
> tomcat keystore of the STS must be in the certificate chain of the IDP to
> establish an SSL connection successfully.
>
> The following html page illustrates the usage of the different keys:
>
> http://svn.apache.org/viewvc/cxf/fediz/trunk/examples/samplekeys/HowToGenerateKeysREADME.html?view=co
>
> You must use the tomcat-idp.jks for the https settings in tomcat:
>
> http://svn.apache.org/viewvc/cxf/fediz/trunk/examples/samplekeys/tomcat-idp.jks?view=log
>
> HTH
>
> Oli
>
> ________________________________________
> From: Iván Brencsics [ivan.brencsics@gmail.com]
> Sent: 03 June 2013 12:24
> To: users@cxf.apache.org
> Subject: Re: WS-Trust token handling
>
> Hi Oliver,
>
> Thanks for your answers, all you recommened has been working. I followed
> your blogs, and managed to make running the STS, IDP, RP, and the web
> service client (with tomcat plugin). But only with the 1.0.0 version. In
> case of later Fediz releases there is problem with the tomcat keystore.
>
> * In 1.0.0 the tomcat keytstore has a key with the following cert:
> CN=localhost, SHA1: FE:B6.... The IDP has this cert in its truststore
> * In 1.1.0-SNAPSHOT the IDP trusts this cert: CN=localhost, SHA1: A6:BC...
>
> I know very well that I could generate the keys/keystores by myself, but
> first I would prefer running your examples as they are, as they come out
> from github. Could you please share with me the tomcat keystore you are
> using currently, that the current IDP trusts?
>
> Thank you very much, kind regards,
> Ivan
> +49 179 3814022
>
>
>
>
>
> 2013/5/27 Oliver Wulff <ow...@talend.com>
>
> > Hi
> >
> > 1) Yes, CXF supports caching the token per user dependent on AppliesTo
> and
> > Lifetime. So each component must have a different AppliesTo value.
> >
> > 2) This is supported. Just use the WebServiceContext API. Fixed here:
> > https://issues.apache.org/jira/browse/CXF-4212
> >
> > The following example uses this API:
> >
> >
> http://svn.apache.org/viewvc/cxf/fediz/trunk/examples/wsclientWebapp/webservice/
> >
> > 3) Never tested.
> >
> > Thanks
> > Oli
> >
> >
> > ------
> >
> > Oliver Wulff
> >
> > Blog: http://owulff.blogspot.com
> > Solution Architect
> > http://coders.talend.com
> >
> > Talend Application Integration Division http://www.talend.com
> >
> > ________________________________________
> > From: Iván Brencsics [ivan.brencsics@gmail.com]
> > Sent: 26 May 2013 00:48
> > To: users@cxf.apache.org
> > Subject: WS-Trust token handling
> >
> > Hello,
> >
> > I need to design a distributed software architecture that implements SSO
> > with WS-Trust/SAML. I have made some experiments, read the excellent
> blogs
> > of the Talend colleagues, and now I have an idea how WS-Trust is working.
> >
> > I would just have three questions:
> >
> > 1) In my architecture, there are many components that call each other via
> > SOAP. The idea is that when the first component is triggered, it
> acquires a
> > SAML token from the STS, and then during the subsequent calls this single
> > token is used until the workflow is completed. So lets say 1) the module
> no
> > 1 is triggered; 2) it acquires a SAML token; 3) calls module no 2; 4)
> when
> > module no 2 calls module no 3, the same SAML token is transmitted. Is
> this
> > possible with the CXF implementation?
> >
> > 2) I need to put claims in the token (eg roles). I saw in a blog how to
> do
> > that. But on the receiving side, what is the best way to evaluate the
> > claims found in the received token? For instance, how to retrieve the
> role
> > claims? Should I implement some interceptor for that?
> >
> > 3) I would prefer using SOAP over JMS. Is every WS-Trust operation
> working
> > over JMS the same way as over HTTP?
> >
> > Thank you in advance.
> >
> > Kind regards,
> > Ivan
> >
>
RE: WS-Trust token handling
Posted by Oliver Wulff <ow...@talend.com>.
Hi Ivan
The IDP doesn't trust somebody. Instead, the application (relying party) trusts the IDP/STS. In this case, the signer is within the stsstore.jks:
http://svn.apache.org/viewvc/cxf/fediz/trunk/services/sts/src/main/resources/stsstore.jks?view=log
This certificate hasn't been changed.
But maybe you mean the communication between the IDP and STS where the tomcat keystore of the STS must be in the certificate chain of the IDP to establish an SSL connection successfully.
The following html page illustrates the usage of the different keys:
http://svn.apache.org/viewvc/cxf/fediz/trunk/examples/samplekeys/HowToGenerateKeysREADME.html?view=co
You must use the tomcat-idp.jks for the https settings in tomcat:
http://svn.apache.org/viewvc/cxf/fediz/trunk/examples/samplekeys/tomcat-idp.jks?view=log
HTH
Oli
________________________________________
From: Iván Brencsics [ivan.brencsics@gmail.com]
Sent: 03 June 2013 12:24
To: users@cxf.apache.org
Subject: Re: WS-Trust token handling
Hi Oliver,
Thanks for your answers, all you recommened has been working. I followed
your blogs, and managed to make running the STS, IDP, RP, and the web
service client (with tomcat plugin). But only with the 1.0.0 version. In
case of later Fediz releases there is problem with the tomcat keystore.
* In 1.0.0 the tomcat keytstore has a key with the following cert:
CN=localhost, SHA1: FE:B6.... The IDP has this cert in its truststore
* In 1.1.0-SNAPSHOT the IDP trusts this cert: CN=localhost, SHA1: A6:BC...
I know very well that I could generate the keys/keystores by myself, but
first I would prefer running your examples as they are, as they come out
from github. Could you please share with me the tomcat keystore you are
using currently, that the current IDP trusts?
Thank you very much, kind regards,
Ivan
+49 179 3814022
2013/5/27 Oliver Wulff <ow...@talend.com>
> Hi
>
> 1) Yes, CXF supports caching the token per user dependent on AppliesTo and
> Lifetime. So each component must have a different AppliesTo value.
>
> 2) This is supported. Just use the WebServiceContext API. Fixed here:
> https://issues.apache.org/jira/browse/CXF-4212
>
> The following example uses this API:
>
> http://svn.apache.org/viewvc/cxf/fediz/trunk/examples/wsclientWebapp/webservice/
>
> 3) Never tested.
>
> Thanks
> Oli
>
>
> ------
>
> Oliver Wulff
>
> Blog: http://owulff.blogspot.com
> Solution Architect
> http://coders.talend.com
>
> Talend Application Integration Division http://www.talend.com
>
> ________________________________________
> From: Iván Brencsics [ivan.brencsics@gmail.com]
> Sent: 26 May 2013 00:48
> To: users@cxf.apache.org
> Subject: WS-Trust token handling
>
> Hello,
>
> I need to design a distributed software architecture that implements SSO
> with WS-Trust/SAML. I have made some experiments, read the excellent blogs
> of the Talend colleagues, and now I have an idea how WS-Trust is working.
>
> I would just have three questions:
>
> 1) In my architecture, there are many components that call each other via
> SOAP. The idea is that when the first component is triggered, it acquires a
> SAML token from the STS, and then during the subsequent calls this single
> token is used until the workflow is completed. So lets say 1) the module no
> 1 is triggered; 2) it acquires a SAML token; 3) calls module no 2; 4) when
> module no 2 calls module no 3, the same SAML token is transmitted. Is this
> possible with the CXF implementation?
>
> 2) I need to put claims in the token (eg roles). I saw in a blog how to do
> that. But on the receiving side, what is the best way to evaluate the
> claims found in the received token? For instance, how to retrieve the role
> claims? Should I implement some interceptor for that?
>
> 3) I would prefer using SOAP over JMS. Is every WS-Trust operation working
> over JMS the same way as over HTTP?
>
> Thank you in advance.
>
> Kind regards,
> Ivan
>
Re: WS-Trust token handling
Posted by Iván Brencsics <iv...@gmail.com>.
Hi Oliver,
Thanks for your answers, all you recommened has been working. I followed
your blogs, and managed to make running the STS, IDP, RP, and the web
service client (with tomcat plugin). But only with the 1.0.0 version. In
case of later Fediz releases there is problem with the tomcat keystore.
* In 1.0.0 the tomcat keytstore has a key with the following cert:
CN=localhost, SHA1: FE:B6.... The IDP has this cert in its truststore
* In 1.1.0-SNAPSHOT the IDP trusts this cert: CN=localhost, SHA1: A6:BC...
I know very well that I could generate the keys/keystores by myself, but
first I would prefer running your examples as they are, as they come out
from github. Could you please share with me the tomcat keystore you are
using currently, that the current IDP trusts?
Thank you very much, kind regards,
Ivan
+49 179 3814022
2013/5/27 Oliver Wulff <ow...@talend.com>
> Hi
>
> 1) Yes, CXF supports caching the token per user dependent on AppliesTo and
> Lifetime. So each component must have a different AppliesTo value.
>
> 2) This is supported. Just use the WebServiceContext API. Fixed here:
> https://issues.apache.org/jira/browse/CXF-4212
>
> The following example uses this API:
>
> http://svn.apache.org/viewvc/cxf/fediz/trunk/examples/wsclientWebapp/webservice/
>
> 3) Never tested.
>
> Thanks
> Oli
>
>
> ------
>
> Oliver Wulff
>
> Blog: http://owulff.blogspot.com
> Solution Architect
> http://coders.talend.com
>
> Talend Application Integration Division http://www.talend.com
>
> ________________________________________
> From: Iván Brencsics [ivan.brencsics@gmail.com]
> Sent: 26 May 2013 00:48
> To: users@cxf.apache.org
> Subject: WS-Trust token handling
>
> Hello,
>
> I need to design a distributed software architecture that implements SSO
> with WS-Trust/SAML. I have made some experiments, read the excellent blogs
> of the Talend colleagues, and now I have an idea how WS-Trust is working.
>
> I would just have three questions:
>
> 1) In my architecture, there are many components that call each other via
> SOAP. The idea is that when the first component is triggered, it acquires a
> SAML token from the STS, and then during the subsequent calls this single
> token is used until the workflow is completed. So lets say 1) the module no
> 1 is triggered; 2) it acquires a SAML token; 3) calls module no 2; 4) when
> module no 2 calls module no 3, the same SAML token is transmitted. Is this
> possible with the CXF implementation?
>
> 2) I need to put claims in the token (eg roles). I saw in a blog how to do
> that. But on the receiving side, what is the best way to evaluate the
> claims found in the received token? For instance, how to retrieve the role
> claims? Should I implement some interceptor for that?
>
> 3) I would prefer using SOAP over JMS. Is every WS-Trust operation working
> over JMS the same way as over HTTP?
>
> Thank you in advance.
>
> Kind regards,
> Ivan
>
RE: WS-Trust token handling
Posted by Oliver Wulff <ow...@talend.com>.
Hi
1) Yes, CXF supports caching the token per user dependent on AppliesTo and Lifetime. So each component must have a different AppliesTo value.
2) This is supported. Just use the WebServiceContext API. Fixed here:
https://issues.apache.org/jira/browse/CXF-4212
The following example uses this API:
http://svn.apache.org/viewvc/cxf/fediz/trunk/examples/wsclientWebapp/webservice/
3) Never tested.
Thanks
Oli
------
Oliver Wulff
Blog: http://owulff.blogspot.com
Solution Architect
http://coders.talend.com
Talend Application Integration Division http://www.talend.com
________________________________________
From: Iván Brencsics [ivan.brencsics@gmail.com]
Sent: 26 May 2013 00:48
To: users@cxf.apache.org
Subject: WS-Trust token handling
Hello,
I need to design a distributed software architecture that implements SSO
with WS-Trust/SAML. I have made some experiments, read the excellent blogs
of the Talend colleagues, and now I have an idea how WS-Trust is working.
I would just have three questions:
1) In my architecture, there are many components that call each other via
SOAP. The idea is that when the first component is triggered, it acquires a
SAML token from the STS, and then during the subsequent calls this single
token is used until the workflow is completed. So lets say 1) the module no
1 is triggered; 2) it acquires a SAML token; 3) calls module no 2; 4) when
module no 2 calls module no 3, the same SAML token is transmitted. Is this
possible with the CXF implementation?
2) I need to put claims in the token (eg roles). I saw in a blog how to do
that. But on the receiving side, what is the best way to evaluate the
claims found in the received token? For instance, how to retrieve the role
claims? Should I implement some interceptor for that?
3) I would prefer using SOAP over JMS. Is every WS-Trust operation working
over JMS the same way as over HTTP?
Thank you in advance.
Kind regards,
Ivan