I describe on the following blog entry how to configure an ASP.NET application
with Windows Identity Foundation (WIF is included in .NET 4.5):
http://owulff.blogspot.ch/2012/02/configure-fediz-idp-and-aspnet-using.html
Oli
--
Oliver Wulff
Blog: http://owulff.blogspot.com
Solution Architec
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 [rpar...@indigoconsulting.com]
Sent: 08 October 2014 19:16
To: users@cxf.apache.org
Subject:
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,
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 un
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
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
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
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 cou
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 pu
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
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 imple
Hi
On 08/10/14 11:38, Anders Clausen wrote:
Hi
We're using CXF for our REST and SOAP web services. All of our calls
normally go through a separate security layer. However, in some of our test
environments we haven't got the security layer in place, so when we test
calls to our SOAP web services
Colm -
It looks like I have a solution for this. I had extracted some code to post to
the OpenSAML list, and posted the problem over there. While waiting for
something to happen, I tried a few things with the extracted code, mostly with
no positive changes. But then I tried this change, and now
Hi there,
I am implementing a contract first webservice implementation with a
provided wsdl using Grails and CXF.
When trying to serve the wsdl from a url such as http://localhost:8080/
/services/?wsdl
By just using the browser, I get a response:
http://schemas.xmlsoap.org/soap/envelope/";>
Hi
We're using CXF for our REST and SOAP web services. All of our calls
normally go through a separate security layer. However, in some of our test
environments we haven't got the security layer in place, so when we test
calls to our SOAP web services we get an error from the
MustUnderstandInterce
You can also set a property on the bus if you don't want to use a system
property. Makes it simpler to define in spring.
On 08/10/2014 8:27 PM, "Malisetti, Ramanjaneyulu" <
ramanjaneyulu.malise...@ca.com> wrote:
> That helps. We will wait for 3.0.2.
>
> Thank you.
>
> Regards
> Raman
>
> -Ori
That helps. We will wait for 3.0.2.
Thank you.
Regards
Raman
-Original Message-
From: Sergey Beryozkin [mailto:sberyoz...@gmail.com]
Sent: Wednesday, October 08, 2014 2:53 PM
To: users@cxf.apache.org; d...@cxf.apache.org
Subject: Re: conflicts with the registered path
Hi
Redirecting
Hi
Redirecting to the users list
Apparently supporting overlapping addresses was causing issues in other
cases where the Jetty transport was used and it was restricted in 3.0.1.
CXF 3.0.2 (the release process is about to start) has a
"org.apache.cxf.transports.http_jetty.DontCheckUrl" system
18 matches
Mail list logo
