Return-Path: X-Original-To: apmail-cxf-users-archive@www.apache.org Delivered-To: apmail-cxf-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 22FDC11220 for ; Mon, 7 Jul 2014 09:00:36 +0000 (UTC) Received: (qmail 89722 invoked by uid 500); 7 Jul 2014 09:00:35 -0000 Delivered-To: apmail-cxf-users-archive@cxf.apache.org Received: (qmail 89656 invoked by uid 500); 7 Jul 2014 09:00:35 -0000 Mailing-List: contact users-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@cxf.apache.org Delivered-To: mailing list users@cxf.apache.org Received: (qmail 89643 invoked by uid 99); 7 Jul 2014 09:00:35 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Jul 2014 09:00:35 +0000 X-ASF-Spam-Status: No, hits=2.0 required=5.0 tests=SPF_NEUTRAL,URI_HEX X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [216.139.236.26] (HELO sam.nabble.com) (216.139.236.26) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Jul 2014 09:00:33 +0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1X44mO-0004dg-S5 for users@cxf.apache.org; Mon, 07 Jul 2014 02:00:08 -0700 Date: Mon, 7 Jul 2014 02:00:08 -0700 (PDT) From: coheigea To: users@cxf.apache.org Message-ID: In-Reply-To: <1404715670813-5746057.post@n5.nabble.com> References: <1403501772305-5745465.post@n5.nabble.com> <1403512245927-5745470.post@n5.nabble.com> <1403519739520-5745474.post@n5.nabble.com> <1403525511680-5745487.post@n5.nabble.com> <1403853671702-5745699.post@n5.nabble.com> <1404227397374-5745822.post@n5.nabble.com> <1404715670813-5746057.post@n5.nabble.com> Subject: Re: Issue with WS-Trust using security tokens/SAML assertions MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Sorry, I don't follow you. Could you outline how you expect the token flow to work in detail? From my POV, if the STS requires an IssuedToken, the client must obtain this token from another STS instance. Colm. On Mon, Jul 7, 2014 at 7:47 AM, roband915 [via CXF] < ml-node+s547215n5746057h94@n5.nabble.com> wrote: > The Shibboleth SP that we're using actually communicates with the same STS > as the webapplication should do. So there is only one STS. > > When my Shibboleth SP recieves the token from the ADFS, Isn't the ADFS > then "aware" that there is a valid token sent to this client? So when I via > the webapplication call the "Issued-token" on the ADFS it can respond with > the already existing token? > > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://cxf.547215.n5.nabble.com/Issue-with-WS-Trust-using-security-tokens-SAML-assertions-tp5744142p5746057.html > To unsubscribe from Issue with WS-Trust using security tokens/SAML > assertions, click here > > . > NAML > > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com -- View this message in context: http://cxf.547215.n5.nabble.com/Issue-with-WS-Trust-using-security-tokens-SAML-assertions-tp5744142p5746062.html Sent from the cxf-user mailing list archive at Nabble.com.