-
1. Re: Picketlink wishlist
anil.saldhana Dec 16, 2010 8:29 PM (in response to acoliver)
wishlist:
1. Fix logging (like why are parse errors "trace" when fatal)Anil: definitely has to be fixed. I think we need to just show the errors in the logs. Hopefully no INFO type xml cr$p.
2. Error handling (li...ke "I must have a nameID here)
Anil: We try to do that but may have cracks.
3. simplified codebase (sounds like you're doing that), probably most users won't notice but if it makes me happy it will pay off for a lot more people :-)
Anil: Actually the modules are broken into functionality and tomcat, jboss and regular web dependencies. I know it may seem like a nightmare to debug but if you bring in the entire workspace into eclipse, then the debugging is quite easy. PL2 will be better and will definitely take your feedback seriously.
4. Documentation. One should be the 10-page primer, another should be the 1000 page reference (ideally not 1000 pages)
Anil: This is security and I can guarantee a zillion configuration options. Will try to document.
5. Loose the separate valves and just have one that finds out how to behave from the config. (Basically a valve that delegates to the real valve).
Anil: On the IDP side, the IDPSSOValve is the king. On the SP side, we have many valves. We definitely have to work on the SP valve unification if possible.
6. Document your testcase stuff (cause so far everyone you have referred to the testcases says "umm huh where is the config?" and I don't get it either)
7. APR/OpenSSL support (granted this is outside of picketlink in particular but I kinda think JSSE should be taken out and shot) - meaning able to use native/openssl instead of keystores and jsseAnil: That is latin to me.
-
2. Re: Picketlink wishlist
acoliver Dec 16, 2010 10:15 PM (in response to anil.saldhana)Tomcat has the "APR Connector" (http://tomcat.apache.org/tomcat-6.0-doc/config/http.html) which uses Apache Portable Runtime. This uses JNI and OpenSSL to implement SSL instead of JSSE (Java's SSL) and Keystores. Not only is the configuration actually simpler but OpenSSL runs rings around JSSE. JBossNative includes this stuff (stock basically). What is missing is a general library (possibly a provider for JSSE: http://download.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html). Also when you go web services you obviously go over JSSE/SSL regardless of what Tomcat is doing. With a general library you could avoid the difficult to configure/manage, poor performing, GC intensive JSSE and entirely have a native OpenSSL implementation. Fallback should be to pure-java JSSE of course but presumably most peopel would opt for better perforamance and ease of config even if it meant unzipping the native stuff into jboss/bin.
-
3. Picketlink wishlist
blawrence Jan 20, 2011 10:53 AM (in response to anil.saldhana)I would love to add a few things to this "wishlist" if possible.
I've been using PicketLink strickly as an SP in conjunction with a Shibboleth IDP.
I've had to make a few changes to the SP classes to get things working, but other than that, things seem to work great.
Now - my issues with the framework...some of these may be simple bug fixes (I'm using the 1.0.4 codebase)...
1) The SAML2AuthenticationHandler only uses the first attribute statement to find role names even though there could potentially be many. I had to modify the code to loop over all attribute statements to find all the role names.
2) The SPRedirect/PostFormAuthenticators don't call the saveRequest method on the BaseFormAuthenticator superclass before sending the request to the IDP. Calling this method stores the original requested URL in the session and this is how JBoss knows where to redirect you after authentication when you try to access a protected resource...just like with regular form-based authentication. Either this or adding an additional "target" query parameter to the IDP url so that once authenticated, this param is passed back along with the SAML response and the authenticators can use that param to redirect the user to where they originally wanted to go (this is part of the SAML spec I think).
3) Hardcoded service provider URLs in the config files. I realize that the framework needs to know where the IDP is to direct the client, but why does it need the SP url? What if my SP is sitting behind a reverse proxy? My app could potentially be accessed directly or through the proxy, but with the current config, this won't work properly. Why can't the authenticators (SPRedirect/PostFormAuthenticators) that send the client to the IDP use the HttpServletRequest to compute the SP url? You can get the server name, port #, context path, etc. Or better yet, simply set the original requested/target url as the AssertionConsumerServerURL in the SAML request since all the handling on the SP side is done via a filter. It just seems that the service provider url is unnecessary...
4) Picketlink uses the ServiceURL from the config as the SAML request issuer. This is kinda related to #3 above. The SAML issuer corresponds to the relying party entity ID for the Shibboleth IDP and the IDP uses this value to determine if it has metadata for the SP. Since this is always the url of the web app, it means that for every web application that I want to have SSO-enabled, I need to add yet another relying party configuration with metadata to the IDP with all the exact same information except the relying party entity ID (SAML request issuer). The only way around this is to allow anonymous relying parties on the Shibboleth end...something I'd really like to stay away from if possible. Basically I'd like to see a change to the config that replaces the ServiceURL with an IssuerID or something.
If these things could be addressed, it would definitely help improve the interoperability of the framework.
Oh yea - one more thing...it would be nice to see whats on the menu for PicketLink v2. I cannot find this anywhere.
-
4. Picketlink wishlist
anil.saldhana Jan 24, 2011 10:19 AM (in response to blawrence)Bobby, it is very unfortunate that you had to make changes to the PL codebase to make it work with Shibboleth IDP. We are in need of interoperability with various IDPs in the industry.
I am surprised that you were not able to create a JIRA report on the bugs that you encountered so that others could benefit from the reports.
I am also wondering if you would like to submit patches? This is an open source project and we freely grant commit rights and freedom.
-
5. Picketlink wishlist
blawrence Jan 24, 2011 10:27 AM (in response to anil.saldhana)Well - I haven't found the time to create a bug report as I've just been playing with the PicketLink SP codebase...it also seems that someone else has also encountered some of these issues and was also asked to be a committer:
http://community.jboss.org/message/71356
I would be more than happy to work on the project and try to make it interoperable with the Shibboleth IDP...I just didn't want to be making the same changes as other folks working on the project.
-
6. Picketlink wishlist
anil.saldhana Jan 27, 2011 1:25 PM (in response to blawrence)Bobby, based on your feedback, I have incorporated the following JIRAs into the PL2 code base. I am planning to put out a build next week. I will appreciate if you can test when I put out the build.
https://issues.jboss.org/browse/PLFED-130
https://issues.jboss.org/browse/PLFED-128
https://issues.jboss.org/browse/PLFED-124
-
7. Picketlink wishlist
blawrence Mar 31, 2011 10:23 AM (in response to anil.saldhana)Anil -
I haven't seen any new builds recently.
Do you want some help incorporating the changes to the codebase?
If so, I would gladly step on as a committer to the project..
-
8. Picketlink wishlist
anil.saldhana Mar 31, 2011 10:33 AM (in response to blawrence)Bobby, I was planning on releasing M1 last friday, but got sick. Hopefully tomorrow. After the M1, we will continue with regular snapshot builds for people to test.
wishlist:
1. Fix logging (like why are parse errors "trace" when fatal)
2. Error handling (li...ke "I must have a nameID here)
3. simplified codebase (sounds like you're doing that), probably most users won't notice but if it makes me happy it will pay off for a lot more people :-)
4. Documentation. One should be the 10-page primer, another should be the 1000 page reference (ideally not 1000 pages)
5. Loose the separate valves and just have one that finds out how to behave from the config. (Basically a valve that delegates to the real valve).
6. Document your testcase stuff (cause so far everyone you have referred to the testcases says "umm huh where is the config?" and I don't get it either)
7. APR/OpenSSL support (granted this is outside of picketlink in particular but I kinda think JSSE should be taken out and shot) - meaning able to use native/openssl instead of keystores and jsse
I'll post some jiras when I'm not sick and in a frozen place.