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 [[email protected]]
Sent: 08 October 2014 19:16
To: [email protected]
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 [[email protected]]
Sent: 07 October 2014 12:16
To: [email protected]
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
