Re: Fediz Tomcat plug-in and Shibboleth IdP
I am trying to map the different values required by fediz plugin to talk to our Shibboleth IdP. Any help is much appreciated. What kind of help are you looking for? Is the Fediz plugin making an invocation on the Shibboleth IdP that is rejected? If so please post the exception and we might be able to help. Colm. On Tue, Mar 19, 2013 at 2:16 PM, Abba Yadav a...@usp.org wrote: I am trying to integrate Fediz Tomcat plug-in to talk to our Shibboleth IdP. The Fediz tomcat plug-in on the Service Provider talks SAML 1.0. Sample Fediz configuration file looks like this: ?xml version=1.0 encoding=UTF-8 standalone=yes? !-- Place in Tomcat conf folder or other location as designated in this sample's webapp/META-INF/context.xml file. Keystore referenced below must have IDP STS' public cert included in it. This example re-uses the Tomcat SSL keystore (tomcat-rp.jks) for this task; alternatively you may wish to use a Fediz-specific keystore instead. -- FedizConfig contextConfig name=/fedizhelloworld audienceUris audienceItem https://localhost:8443/fedizhelloworld//audienceItem https://localhost:8443/fedizhelloworld/%3C/audienceItem /audienceUris certificateStores trustManager keyStore file=tomcat-rp.jks password=tompass type=JKS / /trustManager /certificateStores trustedIssuers issuer subject=.*CN=www.sts.com.* certificateValidation=ChainTrust name=DoubleItSTSIssuer / /trustedIssuers maximumClockSkew1000/maximumClockSkew protocol xmlns:xsi= http://www.w3.org/2001/XMLSchema-instance; http://www.w3.org/2001/XMLSchema-instance%22 xsi:type=federationProtocolType version=1.0.0 !--realmtarget realm/realm-- issuer https://localhost:9443/fedizidp//issuer https://localhost:9443/fedizidp/%3C/issuer roleDelimiter,/roleDelimiter roleURI http://schemas.xmlsoap.org/ws/2005/05/identity/claims/role/roleURI http://schemas.xmlsoap.org/ws/2005/05/identity/claims/role%3C/roleURI !--authenticationType type=Stringsome auth type/authenticationType-- !--homeRealm type=Classorg.apache.fediz.realm.MyHomeRealm/homeRealm-- !--freshness0/freshness-- !--replyreply value/reply-- !--requestREQUEST/request-- claimTypesRequested claimType type=a particular claim type optional=true / /claimTypesRequested /protocol /contextConfig /FedizConfig I am trying to map the different values required by fediz plugin to talk to our Shibboleth IdP. Any help is much appreciated. Thanks, Abba -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
RE: Thoughts about a 2.8 release (or not)…
+1 for skipping 2.8 and releasing 3.0 end of this year. @Sergei: let us to discuss how I could help with 2.0 TCK. Regards, Andrei. -Original Message- From: Daniel Kulp [mailto:dk...@apache.org] Sent: Montag, 25. März 2013 19:19 To: dev@cxf.apache.org Subject: Thoughts about a 2.8 release (or not)… We're getting close to April which normally would be the next release (2.8). However, looking things over, I'm not sure it makes sense at this time. Looking at trunk, the only major change (which is admittedly a big one), is updating the JAX-RS 2.0 stuff from m10 to the RC level. However, it's not complete yet. Almost everything else has been back ported to 2.7.x. The other major chunk of work that is happening is on the wss4j2 branch, but that isn't ready for for release yet either. (and has some backwards compat issues to resolve if it would go on a 2.x line) According to the agreements Apache has with Oracle, we really cannot release code that doesn't pass the TCK (which the 2.0 works would not). Technically, we should not have released 2.7.0 as a release. We can release things like tech previews or beta or similar, but not a full release. Since we are working on trying to renew the agreements, Oracle is paying attention to us pretty closely right now. So, what am I getting at? In order to release 2.8 in a few weeks, we'd either need to back out all the JAX-RS 2.0 stuff to 1.1 level OR everyone jump in full force and get it to pass the TCK. I really don't see either happening. Backing out to 1.1 would be silly and the 2.0 TCK stuff is a ton of work. Thus, my suggestion would be to skip a big release this April and concentrate on bigger things for our Oct/Nov release. Possibly make that a CXF 3.0 release instead of 2.8 where we can clean up some stuff, break a few things (like change the couple API's that currently force WSDL4J on JAX-RS users), etc…We can incorporate the WSS4J2 changes as part of this as well.If we go this route, we could likely start a series of beta releases or similar in June or so to get people looking at it and testing with it. Any thoughts? -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Thoughts about a 2.8 release (or not)…
Dan's quote: According to the agreements Apache has with Oracle, we really cannot release code that doesn't pass the TCK (which the 2.0 works would not). I'm confused -- Apache FOP, Maven and Tomcat can release whenever they want, even though none of them even remotely pass the JAX-RS TCK either. Can you spell out precisely why CXF has that restriction? Apache makes maybe 100 software products, which of them are allowed to be released even though they horribly fail the JAX-RS TCK and which ones aren't? Oracle is a competitor, it would be strange for us to sign up for something that limits our ability to make releases (which is what a competitor would want). Further, there is so much more to CXF than just adherence to any one particular TCK, it would seem to our heavy detriment if we could no longer make releases to make that additional functionality available to the community (allowing them to work on it, adopt it, and report bugs to us) just because of incomplete TCK compliance in one specification or the other. This also seems to give Oracle an advantage of sorts--Oracle splits its services offerings into Metro and Jersey, so a failure in one would mean the other still can get released. With CXF, which supports 2 TCK's, if either fail then the entire product line can't be released. Always smelling a rat, Glen -- View this message in context: http://cxf.547215.n5.nabble.com/Thoughts-about-a-2-8-release-or-not-tp5725179p5725412.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: svn commit: r1461738 - /cxf/trunk/rt/rs/security/cors/src/main/java/org/apache/cxf/rs/security/cors/CrossOriginResourceSharingFilter.java
Dan, thanks for the fix, I actually did not include the local CORS
update, sorry
Sergey
On 27/03/13 20:47, dk...@apache.org wrote:
Author: dkulp
Date: Wed Mar 27 17:47:25 2013
New Revision: 1461738
URL: http://svn.apache.org/r1461738
Log:
Fix tests by allowing for the null return.
Modified:
cxf/trunk/rt/rs/security/cors/src/main/java/org/apache/cxf/rs/security/cors/CrossOriginResourceSharingFilter.java
Modified:
cxf/trunk/rt/rs/security/cors/src/main/java/org/apache/cxf/rs/security/cors/CrossOriginResourceSharingFilter.java
URL:
http://svn.apache.org/viewvc/cxf/trunk/rt/rs/security/cors/src/main/java/org/apache/cxf/rs/security/cors/CrossOriginResourceSharingFilter.java?rev=1461738r1=1461737r2=1461738view=diff
==
---
cxf/trunk/rt/rs/security/cors/src/main/java/org/apache/cxf/rs/security/cors/CrossOriginResourceSharingFilter.java
(original)
+++
cxf/trunk/rt/rs/security/cors/src/main/java/org/apache/cxf/rs/security/cors/CrossOriginResourceSharingFilter.java
Wed Mar 27 17:47:25 2013
@@ -491,10 +491,12 @@ public class CrossOriginResourceSharingF
splitPattern = FIELD_COMMA_PATTERN;
}
ListString results = new ArrayListString();
-for (String value : values) {
-String[] items = splitPattern.split(value);
-for (String item : items) {
-results.add(item.trim());
+if (values != null) {
+for (String value : values) {
+String[] items = splitPattern.split(value);
+for (String item : items) {
+results.add(item.trim());
+}
}
}
return results;
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: Thoughts about a 2.8 release (or not)…
Hi Andrei On 27/03/13 18:24, Andrei Shakirin wrote: +1 for skipping 2.8 and releasing 3.0 end of this year. @Sergei: let us to discuss how I could help with 2.0 TCK. I'm trying to get the server part close enough to be tested against TCK. There are 3 issues which I'm aware at the moment that need to be completed: 1. support for server-side media type quality parameters (;qs), this is needed 2. support fro injection of Configuration context - should be straightforward enough 3. bean validation support - the latter is important but has just been confirmed to be an optional feature - that said I think we can probably get it done for RS but also for WS I think only 1 is required at this stage to start working with TCK, plus minor bits and pieces to be fixed to get (server-part) TCK passed :-). The TCK we have is not final but should be close enough to the final one. The client implementations tests will be done later in the year I'll get back to you once I do an initial run later on Thanks Sergey Regards, Andrei. -Original Message- From: Daniel Kulp [mailto:dk...@apache.org] Sent: Montag, 25. März 2013 19:19 To: dev@cxf.apache.org Subject: Thoughts about a 2.8 release (or not)… We're getting close to April which normally would be the next release (2.8). However, looking things over, I'm not sure it makes sense at this time. Looking at trunk, the only major change (which is admittedly a big one), is updating the JAX-RS 2.0 stuff from m10 to the RC level. However, it's not complete yet. Almost everything else has been back ported to 2.7.x. The other major chunk of work that is happening is on the wss4j2 branch, but that isn't ready for for release yet either. (and has some backwards compat issues to resolve if it would go on a 2.x line) According to the agreements Apache has with Oracle, we really cannot release code that doesn't pass the TCK (which the 2.0 works would not). Technically, we should not have released 2.7.0 as a release. We can release things like tech previews or beta or similar, but not a full release. Since we are working on trying to renew the agreements, Oracle is paying attention to us pretty closely right now. So, what am I getting at? In order to release 2.8 in a few weeks, we'd either need to back out all the JAX-RS 2.0 stuff to 1.1 level OR everyone jump in full force and get it to pass the TCK. I really don't see either happening. Backing out to 1.1 would be silly and the 2.0 TCK stuff is a ton of work. Thus, my suggestion would be to skip a big release this April and concentrate on bigger things for our Oct/Nov release. Possibly make that a CXF 3.0 release instead of 2.8 where we can clean up some stuff, break a few things (like change the couple API's that currently force WSDL4J on JAX-RS users), etc…We can incorporate the WSS4J2 changes as part of this as well.If we go this route, we could likely start a series of beta releases or similar in June or so to get people looking at it and testing with it. Any thoughts? -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
