Yes, CXF automatically generates the co-located STS. See the following code:
https://github.com/apache/cxf/blob/master/rt/ws/security/src/main/java/org/apache/cxf/ws/security/policy/interceptors/SecureConversationInInterceptor.java#L327 There is an option however to use a standalone STS. See this test-code: https://github.com/apache/cxf/blob/master/services/sts/systests/advanced/src/test/java/org/apache/cxf/systest/sts/secure_conv/SecureConversationTest.java You have to explicitly configure the service provider to send the received SecurityContextToken off to the STS for validation. Colm. On Tue, Aug 15, 2017 at 9:40 AM, pat7 <pat.pichle...@gmail.com> wrote: > Hi, > thx for replay. > > There is no external service provider, only the following points 1) and 2). > > I have implemented/ configured two services > 1) STS > 2) Transferservice (WS secureconversation with BootstrapPolicy) > > I thought that I co-located the 1) STS with the 2) transferservice with the > following "Bean" definition: > > @Bean > public List<String> transportEndpoints(){ > List<String> transportendpoints = new ArrayList<String>(); > > transportendpoints.add("https://localhost:8443/TransferService-2.6.0.1.0 > "); > return transportendpoints; > } > Is the above definition not the correct way to co-locate a STS with a > service provider? > Does CXF generate automatically a dummy STS or is my configured STS the > dummy STS you are talking about? > > I am really new with the WS-* specification. > Thx in advance. > Regards, > Patrick > > > > > -- > View this message in context: http://cxf.547215.n5.nabble. > com/These-policy-alternatives-can-not-be-satisfied-tp5782647p5782685.html > Sent from the cxf-user mailing list archive at Nabble.com. > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
