Mailing-List: contact dev-help@syncope.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@syncope.apache.org
Subject: Re: IdP initiated SAML SSO
To: dev@syncope.apache.org
References: <CAB8XdGBk3-ZopqK13DwCVBicHOoD53bjM=8erP9MED4Tw5BaDA@mail.gmail.com>
From: =?UTF-8?Q?Francesco_Chicchiricc=c3=b2?= <ilgrosso@apache.org>
Message-ID: <693836e4-7cde-e5ca-c7e3-77284c8a4765@apache.org>
Date: Thu, 17 Aug 2017 15:15:45 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CAB8XdGBk3-ZopqK13DwCVBicHOoD53bjM=8erP9MED4Tw5BaDA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
archived-at: Thu, 17 Aug 2017 13:15:53 -0000

On 15/08/2017 18:38, Colm O hEigeartaigh wrote:
> Currently, Syncope only supports RP-initiated SAML SSO. It would be nice to
> support IdP initiated SAML SSO as well.
>
> I have got this working in an interop test with Okta, by commenting out the
> RelayState processing, and removing passing
> relayState.getJwtClaims().getSubject() through to the validation process.
>
> Any thoughts on how best to handle this scenario? Add a configuration
> switch to allow the IdP initiated flow for a given IdP?

Hi Colm,
the relay state processing and validation could be optionally disabled 
according to some switch passed to the Agent by the IdP itself (as a 
request param, for example) and then added by the Agent into the REST 
call which ends up in SAML2SPLogic.

Having a further setting for IdP conf to explicitly authorize 
IdP-initiated scenarios makes sense too, to me.

Regards.

-- 
Francesco Chicchiriccò

Tirasa - Open Source Excellence
http://www.tirasa.net/

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/