Mailing-List: contact users-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cxf.apache.org
Received-SPF: pass (nike.apache.org: domain of sberyozkin@gmail.com designates
 74.125.82.52 as permitted sender)
Message-ID: <54356262.5060003@gmail.com>
Date: Wed, 08 Oct 2014 17:12:18 +0100
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: users@cxf.apache.org
Subject: Re: FEDIZ with external authentication
References: 
 <5432D68E.2090901@indigoconsulting.com>,<5433BD82.2040709@gmail.com>
 <79AB4452999C844D9920E0363533273111BEA746@S10BE002.SH10.lan>
 <54354BE7.2020903@indigoconsulting.com> <54355725.4070201@gmail.com>
 <54355F65.9030800@indigoconsulting.com> <54356024.70709@gmail.com>
 <543561CC.1090705@indigoconsulting.com>
In-Reply-To: <543561CC.1090705@indigoconsulting.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

No, Openid-Connect is an OAuth2 based authentication/SSO mechanism.

On 08/10/14 17:09, Rajeev Parekh wrote:
> well neither is truly an authentication mechanism, both OAuth and OpenID
> Connect will delegate the actual authentication to the Authorization
> Server, OpenID Connect adds the iDToken grant type to convey the details
> of the authentication context. so IMO authentication is orthogonal to
> both OAuth and OpenID Connect
>
> regards
>
> Rajeev Parekh
> Indigo Consulting
> www.indigoconsulting.com
> 847.275.4432 (m)
> 847.304.7800 (w)
>
> At the intersection of consumer, mobile and social identities
>
> On 10/8/2014 11:02 AM, Sergey Beryozkin wrote:
>> OAuth2 is def not an authentication mechanism on its own, putting an
>> equals mark between the two is wrong. But if that works for you then
>> I've no problems with that
>>
>> Cheers, Sergey
>> On 08/10/14 16:59, Rajeev Parekh wrote:
>>> Actually IMO, OAuth or OpenID connect would be the same, in both cases
>>> the authorize end point will redirect to authorization server before
>>> giving a grant (assume code). This code will be returned to FEDIZ IDP,
>>> which will exchange code for an access token. In case of OpenID Connect,
>>> the IDP could further query the userInfo endpoint to get additional
>>> claims/attributes.
>>>
>>> thanks
>>>
>>> Rajeev Parekh
>>> Indigo Consulting
>>> www.indigoconsulting.com
>>> 847.275.4432 (m)
>>> 847.304.7800 (w)
>>>
>>> At the intersection of consumer, mobile and social identities
>>>
>>> On 10/8/2014 10:24 AM, Sergey Beryozkin wrote:
>>>> Are you actually referring to Openid-Connect ? Fediz might natively
>>>> implement it in the future...
>>>>
>>>> Sergey
>>>> On 08/10/14 15:36, Rajeev Parekh wrote:
>>>>> Oli
>>>>>
>>>>> Thank you so much, I will look at the ticket, this should help
>>>>>
>>>>> On 10/8/2014 9:12 AM, Oliver Wulff wrote:
>>>>>> If you use OAuth for authentication purposes only, it should work
>>>>>> with
>>>>>> 1.2 which is not released yet. A JIRA ticket is also open:
>>>>>> https://issues.apache.org/jira/browse/FEDIZ-72
>>>>>>
>>>>>> All you have to do is implement the interface
>>>>>> TrustedIdpProtocolHandler as described in the above Jira.
>>>>>>
>>>>>> You must implement the method mapSignInRequest to create the request
>>>>>> to the OAuth Server and the method mapSignInResponse to map the
>>>>>> response to a security token.
>>>>>>
>>>>>> HTH
>>>>>>
>>>>>> Thanks
>>>>>> Oli
>>>>>>
>>>>>> ________________________________________
>>>>>> From: Sergey Beryozkin [sberyozkin@gmail.com]
>>>>>> Sent: 07 October 2014 12:16
>>>>>> To: users@cxf.apache.org
>>>>>> Subject: Re: FEDIZ with external authentication
>>>>>>
>>>>>> Hi
>>>>>>
>>>>>> On 06/10/14 18:51, Rajeev Parekh wrote:
>>>>>>> I would like to use FEDIZ WS-federation in s setup where
>>>>>>> Authentication
>>>>>>> is delegated to an external OAuth provider.
>>>>>>> Per my understanding, this is more related to configuration with
>>>>>>> Spring
>>>>>>> Security than core FEDIZ, but thought it best to ask this forum for
>>>>>>> advise on how to do it right. My use case is as follows:
>>>>>>>
>>>>>>> 1. User accesses RP
>>>>>>> 2. RP redirects to IDP with signin request
>>>>>>> *3*. IDP should redirect to OAuth provider with grant type = code
>>>>>>> 4. OAuth provider to redirect to Authorization server
>>>>>>> 5. On sucesfull AuthN, OAuth provider to return with code to IDP
>>>>>>> 6. IDP can exchange code for access token and establish identity
>>>>>>> 7. Normal STS flows continue
>>>>>>>
>>>>>> I'm not sure this can work at all. AFAIK this is not how OAuth2
>>>>>> Authorization Service (AS) operates. It returns the code if the user
>>>>>> has
>>>>>> authorized some client application for the latter to exchange for
>>>>>> a new
>>>>>> access token.
>>>>>> In your flow above it reads as if the user would authorize IDP
>>>>>> itself to
>>>>>> the OAuth2 AS.
>>>>>>
>>>>>> Can you clarify why do you it should work ?
>>>>>>
>>>>>> Thanks, Sergey
>>>>>>
>>>>>>> I have read some spring security documentation that suggests the
>>>>>>> approach of extending the
>>>>>>> AbstractPreAuthenticatedProcessingFilter and
>>>>>>> implementing AuthenticationUserDetailsService interface.
>>>>>>> AbstractPreAuthenticatedProcessingFilter assumes that the user has
>>>>>>> been
>>>>>>> authenticated via some other means and the identity can be
>>>>>>> established
>>>>>>> via some http header etc.
>>>>>>> My problem is that, I dont know who is responsible for the initial
>>>>>>> redirection to the external OAuth server, Should I just implement a
>>>>>>> Filter "customOAuthSessionCheckFilter" that does this redirection
>>>>>>> and
>>>>>>> add it to the SpringSecurityFilterChain?
>>>>>>> Some thing like:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>       <filter>
>>>>>>> <filter-name>springSecurityFilterChain</filter-name>
>>>>>>> <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>       </filter>
>>>>>>>
>>>>>>>
>>>>>>>       <filter-mapping>
>>>>>>> <filter-name>springSecurityFilterChain</filter-name>
>>>>>>>           <url-pattern>/*</url-pattern>
>>>>>>>       </filter-mapping>
>>>>>>>
>>>>>>>
>>>>>>>       <bean id="springSecurityFilterChain"
>>>>>>> class="org.springframework.security.util.FilterChainProxy">
>>>>>>>           <sec:filter-chain-map path-type="ant">
>>>>>>>               <sec:filter-chain pattern="/css/**" filters="none"/>
>>>>>>>               <sec:filter-chain pattern="/js/**" filters="none"/>
>>>>>>>               <sec:filter-chain pattern="/img/**" filters="none"/>
>>>>>>>               <sec:filter-chain pattern="/**"
>>>>>>> filters="customOAuthSessionCheckFilter,
>>>>>>> preAuthenticatedProcessingFilter"/>
>>>>>>>           </sec:filter-chain-map>
>>>>>>>       </bean>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sergey Beryozkin
>>>>>>
>>>>>> Talend Community Coders
>>>>>> http://coders.talend.com/
>>>>>>
>>>>>> Blog: http://sberyozkin.blogspot.com
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>