You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Rajeev Parekh <rp...@indigoconsulting.com> on 2014/10/06 19:51:10 UTC
FEDIZ with external authentication
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 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>
RE: FEDIZ with external authentication
Posted by Oliver Wulff <ow...@talend.com>.
sorry, hit "send" to early:
Implementations get registered here: TrustedIdpProtocolControllerImpl. This implementation is called if you redirect to a trusted idp based on the configured protocol.
There is a REST API which allows you to configure applications and trusted idps without having to modify spring configs and restart the idp. The REST interface is described here:
http://owulff.blogspot.ch/2014/01/features-coming-in-fediz-12-rest.html
HTH
Oli
------
Oliver Wulff
Blog: http://owulff.blogspot.com
Solution Architect
http://coders.talend.com
Talend Application Integration Division http://www.talend.com
________________________________________
From: Oliver Wulff [owulff@talend.com]
Sent: 10 October 2014 17:20
To: users@cxf.apache.org
Subject: RE: FEDIZ with external authentication
You find a reference implementation here:
https://git-wip-us.apache.org/repos/asf?p=cxf-fediz.git;a=blob;f=services/idp/src/main/java/org/apache/cxf/fediz/service/idp/protocols/TrustedIdpWSFedProtocolHandler.java;h=0572921d57eaf80fdfcd72aa49312ad19406a995;hb=HEAD
This is the case, where your idp has to establish a trust with another IDP. Right now, only WS-Federation is supported for the protocol. But the interface is there to add another protocol. You just have to deploy an implementation (with annotation @Component) to the WAR file and it gets automatically registered here:
------
Oliver Wulff
Blog: http://owulff.blogspot.com
Solution Architect
http://coders.talend.com
Talend Application Integration Division http://www.talend.com
________________________________________
From: Rajeev Parekh [rparekh@indigoconsulting.com]
Sent: 09 October 2014 15:48
To: users@cxf.apache.org
Subject: Re: FEDIZ with external authentication
Thanks a lot Oli.
Is there a reference implementation that I could start working with.
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/9/2014 1:01 AM, Oliver Wulff wrote:
> Hi there
>
> The interface I mentioned earlier is the reason for the use case you describe and a perfect contribution to the project.
>
> Thanks
> Oli
>
> ________________________________________
> From: Rajeev Parekh [rparekh@indigoconsulting.com]
> Sent: 08 October 2014 19:16
> To: users@cxf.apache.org
> Subject: Re: FEDIZ with external authentication
>
> actually in my case, the FEDIZ IDP is the OAuth2 client, the web
> application requires WS Fed provided by FEDIZ IDP/STS
>
> 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:54 AM, Sergey Beryozkin wrote:
>> Basically, the actual web application protected by Openid-Connect RP
>> is not necessarily an OAuth2 confidential client web application; it
>> may not even participate in OAuth2 flows. Only RP acts as such. Of
>> course, if the web app is an OAuth2 client too then it can also be RP.
>> At least this my understanding of it.
>>
>> Cheers, Sergey
>>
>>
>> On 08/10/14 17:12, Sergey Beryozkin wrote:
>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>
>
>
RE: FEDIZ with external authentication
Posted by Oliver Wulff <ow...@talend.com>.
You find a reference implementation here:
https://git-wip-us.apache.org/repos/asf?p=cxf-fediz.git;a=blob;f=services/idp/src/main/java/org/apache/cxf/fediz/service/idp/protocols/TrustedIdpWSFedProtocolHandler.java;h=0572921d57eaf80fdfcd72aa49312ad19406a995;hb=HEAD
This is the case, where your idp has to establish a trust with another IDP. Right now, only WS-Federation is supported for the protocol. But the interface is there to add another protocol. You just have to deploy an implementation (with annotation @Component) to the WAR file and it gets automatically registered here:
------
Oliver Wulff
Blog: http://owulff.blogspot.com
Solution Architect
http://coders.talend.com
Talend Application Integration Division http://www.talend.com
________________________________________
From: Rajeev Parekh [rparekh@indigoconsulting.com]
Sent: 09 October 2014 15:48
To: users@cxf.apache.org
Subject: Re: FEDIZ with external authentication
Thanks a lot Oli.
Is there a reference implementation that I could start working with.
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/9/2014 1:01 AM, Oliver Wulff wrote:
> Hi there
>
> The interface I mentioned earlier is the reason for the use case you describe and a perfect contribution to the project.
>
> Thanks
> Oli
>
> ________________________________________
> From: Rajeev Parekh [rparekh@indigoconsulting.com]
> Sent: 08 October 2014 19:16
> To: users@cxf.apache.org
> Subject: Re: FEDIZ with external authentication
>
> actually in my case, the FEDIZ IDP is the OAuth2 client, the web
> application requires WS Fed provided by FEDIZ IDP/STS
>
> 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:54 AM, Sergey Beryozkin wrote:
>> Basically, the actual web application protected by Openid-Connect RP
>> is not necessarily an OAuth2 confidential client web application; it
>> may not even participate in OAuth2 flows. Only RP acts as such. Of
>> course, if the web app is an OAuth2 client too then it can also be RP.
>> At least this my understanding of it.
>>
>> Cheers, Sergey
>>
>>
>> On 08/10/14 17:12, Sergey Beryozkin wrote:
>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>
>
>
Re: FEDIZ with external authentication
Posted by Rajeev Parekh <rp...@indigoconsulting.com>.
Thanks a lot Oli.
Is there a reference implementation that I could start working with.
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/9/2014 1:01 AM, Oliver Wulff wrote:
> Hi there
>
> The interface I mentioned earlier is the reason for the use case you describe and a perfect contribution to the project.
>
> Thanks
> Oli
>
> ________________________________________
> From: Rajeev Parekh [rparekh@indigoconsulting.com]
> Sent: 08 October 2014 19:16
> To: users@cxf.apache.org
> Subject: Re: FEDIZ with external authentication
>
> actually in my case, the FEDIZ IDP is the OAuth2 client, the web
> application requires WS Fed provided by FEDIZ IDP/STS
>
> 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:54 AM, Sergey Beryozkin wrote:
>> Basically, the actual web application protected by Openid-Connect RP
>> is not necessarily an OAuth2 confidential client web application; it
>> may not even participate in OAuth2 flows. Only RP acts as such. Of
>> course, if the web app is an OAuth2 client too then it can also be RP.
>> At least this my understanding of it.
>>
>> Cheers, Sergey
>>
>>
>> On 08/10/14 17:12, Sergey Beryozkin wrote:
>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>
>
>
Re: FEDIZ with external authentication
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Oli
Does this interface support one extra redirection ? See step 3 in the
sequence below...The interface implementation in this case would need to
tell IDP that it needs to redirect the user further and then IDP would
need to provide that extra redirect response back to the interface
implementation. It might need a bit of the adjustment ?
Cheers, Sergey
On 09/10/14 07:01, Oliver Wulff wrote:
> Hi there
>
> The interface I mentioned earlier is the reason for the use case you describe and a perfect contribution to the project.
>
> Thanks
> Oli
>
> ________________________________________
> From: Rajeev Parekh [rparekh@indigoconsulting.com]
> Sent: 08 October 2014 19:16
> To: users@cxf.apache.org
> Subject: Re: FEDIZ with external authentication
>
> actually in my case, the FEDIZ IDP is the OAuth2 client, the web
> application requires WS Fed provided by FEDIZ IDP/STS
>
> 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:54 AM, Sergey Beryozkin wrote:
>> Basically, the actual web application protected by Openid-Connect RP
>> is not necessarily an OAuth2 confidential client web application; it
>> may not even participate in OAuth2 flows. Only RP acts as such. Of
>> course, if the web app is an OAuth2 client too then it can also be RP.
>> At least this my understanding of it.
>>
>> Cheers, Sergey
>>
>>
>> On 08/10/14 17:12, Sergey Beryozkin wrote:
>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
RE: FEDIZ with external authentication
Posted by Oliver Wulff <ow...@talend.com>.
Hi there
The interface I mentioned earlier is the reason for the use case you describe and a perfect contribution to the project.
Thanks
Oli
________________________________________
From: Rajeev Parekh [rparekh@indigoconsulting.com]
Sent: 08 October 2014 19:16
To: users@cxf.apache.org
Subject: Re: FEDIZ with external authentication
actually in my case, the FEDIZ IDP is the OAuth2 client, the web
application requires WS Fed provided by FEDIZ IDP/STS
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:54 AM, Sergey Beryozkin wrote:
> Basically, the actual web application protected by Openid-Connect RP
> is not necessarily an OAuth2 confidential client web application; it
> may not even participate in OAuth2 flows. Only RP acts as such. Of
> course, if the web app is an OAuth2 client too then it can also be RP.
> At least this my understanding of it.
>
> Cheers, Sergey
>
>
> On 08/10/14 17:12, Sergey Beryozkin wrote:
>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>
Re: FEDIZ with external authentication
Posted by Rajeev Parekh <rp...@indigoconsulting.com>.
actually in my case, the FEDIZ IDP is the OAuth2 client, the web
application requires WS Fed provided by FEDIZ IDP/STS
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:54 AM, Sergey Beryozkin wrote:
> Basically, the actual web application protected by Openid-Connect RP
> is not necessarily an OAuth2 confidential client web application; it
> may not even participate in OAuth2 flows. Only RP acts as such. Of
> course, if the web app is an OAuth2 client too then it can also be RP.
> At least this my understanding of it.
>
> Cheers, Sergey
>
>
> On 08/10/14 17:12, Sergey Beryozkin wrote:
>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>
Re: FEDIZ with external authentication
Posted by Sergey Beryozkin <sb...@gmail.com>.
Basically, the actual web application protected by Openid-Connect RP is
not necessarily an OAuth2 confidential client web application; it may
not even participate in OAuth2 flows. Only RP acts as such. Of course,
if the web app is an OAuth2 client too then it can also be RP.
At least this my understanding of it.
Cheers, Sergey
On 08/10/14 17:12, Sergey Beryozkin wrote:
> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
Re: FEDIZ with external authentication
Posted by Sergey Beryozkin <sb...@gmail.com>.
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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
Re: FEDIZ with external authentication
Posted by Rajeev Parekh <rp...@indigoconsulting.com>.
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
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
Re: FEDIZ with external authentication
Posted by Sergey Beryozkin <sb...@gmail.com>.
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
>>>>
>>>>
>>>
>>
>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: FEDIZ with external authentication
Posted by Rajeev Parekh <rp...@indigoconsulting.com>.
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
>>>
>>>
>>
>
>
Re: FEDIZ with external authentication
Posted by Sergey Beryozkin <sb...@gmail.com>.
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
>>
>>
>
Re: FEDIZ with external authentication
Posted by Rajeev Parekh <rp...@indigoconsulting.com>.
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
>
>
--
Rajeev Parekh
Indigo Consulting
www.indigoconsulting.com
847.275.4432 (m)
847.304.7800 (w)
At the intersection of consumer, mobile and social identities
RE: FEDIZ with external authentication
Posted by Oliver Wulff <ow...@talend.com>.
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
Re: FEDIZ with external authentication
Posted by Sergey Beryozkin <sb...@gmail.com>.
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