Best Practices for Applying AJAX to JSR 168 Portlets
January 12, 2007 | Leave a Comment
At Plymouth State University we are just beginning to look into JSR 168 portlets for our institution’s portal. This technology for creating channels is just becoming available with the impending release of Luminis IV in Q1 of this year. In doing my initial research on JSR 168, I turned up this interesting article from Greg Ziebold and Marina Sum written in September of 2006.
From the summary/overview:
A year ago, the article Asynchronous Rendering of Portlet Content With AJAX Technology demonstrated how to apply Asynchronous JavaScript and XML (AJAX) to portlets. Since then, AJAX has become increasingly popular in the software arena and many new AJAX technologies have emerged. Examples are JavaScript libraries and toolkits, such as the Dojo Toolkit, the Yahoo! UI Library, the Google Web Toolkit, Script.aculo.us, and DHTML Goodies. In addition, new standards bodies like Open AJAX and the Dojo Foundation are key players.
In light of the many developments in the past year and the host of feedback on how to use AJAX in portlets, this article describes several helpful tips and practices on how best to exploit AJAX in portlets that comply with the Java Specification Request (JSR) 168: Portlet Specification.
The article refers to an updated version of the sample, AJAX Portlet Invoice Viewer, from the original article. You can download the binary Web archive (WAR) file. In the near future, this sample will reside in the Open Source Portlet Repository on java.net.
As we are new to JSR 168 and definitely interested in incorporating Ajax with most any channel we create, this seems like a useful guide.
Tags: AJAX, channel, dojo, greg ziebold, jsr 168, jsr168, luminis, luminis IV, Marina Sum, portal, portlet, xml, yahoo ui
CAMP Shibboleth - Wrap Up
June 29, 2006 | 1 Comment
The following is a wrap-up of what I saw, heard, and hopefully learned from CAMP Shibboleth in Burlington, VT. As always with conferences and workshops, conversations with others and listening to questions asked are usually the most insightful and valuable moments. Much of this may seem scattered in thought, but I need to document these things somewhere…
1) Plymouth State is looking at Shibboleth as a way to accomplish centralized authZ. SunGard sold me on this idea months ago when I could only see Shibb as a federated WebISO solution. I was surprised to see that they are clearly marketing this use case as step two in your implementation plan. Number one is of course to get WebSSO implemented. Both of these are suggested before attacking the politics and policy of extending beyond institutional boundaries. It is clear that this is a smaller step base method that has stages of success. I like this a lot.
2) Shibboleth does attribute release or attribute assertions, not authZ. This seemed like semantics initially, but then I realized from responses to questions that this is an important distinction. Shibboleth could assert in some instances a common name attribute. This has no place in being used for authorization of any sort, but still may be useful, especially with intra-institutional home grown applications. An extremely valuable distinction to understand.
3) I learned that our current implementation methodology of CAS is not ideal. As we rely on an API based mechanism, the authN is coded into our system to rely on CAS. This does not make it as easy to change authN providers or WebSSO solutions as if we used a technology like mod_cas. This explanation from Scott Cantor was illuminating as it gave me a much clearer understanding of how the Shibboleth SP was intended to work when we begin Shibbolizing internal applications.
4) There is an increasing number of federated services becoming available from through third parties that interoperate with Shibboleth. None of these constitutes “the killer app” for Plymouth State University, yet. Of particular note, international federations seem to be moving and forming much quicker than ones in the US. In Europe, a fair number of library related companies appear on their prioritized vendor list including some Plymouth State licenses: EBSCO, JSTOR, and ExLibris.
5) Shibboleth 1.3 can interoperate with federal E-Authentication with a “simple plugin”. This may evolve into our killer application as the Department of Education brings student oriented services online. Currently there are schools using this method to connect so NSF grant applications and the like.
6) The “Where Are You From” (WAYF) concept and implementation has problems. They are even referring to it as “the weakest link.” I’ve had concerns about this, so am happy this is getting attention. In our initial implementation, I believe the simplicity of our environment should allow us to bypass the WAYF. Hopefully WAYF issues will be resolved by the time we start playing in the federated space.
7) When it comes to identity, SunGard’s Luminis causes nearly as many problems as it solves. Others seem to be struggling with this. I’m left wondering if SunGard’s research into the identity management space will eventually lead to some better redesign around this issue.
8) This group has awareness and respect for OpenID. Glad to see this on their radar. When am I getting around to using it?
9) We (Bill Baber, Petr Brym, Ted Wisniewski and myself) met with a representative from the consulting firm Aegis USA. They seem very tuned into what is going on in this space. They also seem to have solid experience working with the Sun Identity Suite which I assume will be a large contender as we work to improve our identity management infrastructure. USNH will be considering them as potential consultant as we look into identity management system wide.
10) Finally some terminology:
IdP - Identity Provider - the core Shibb service that knows who a user is and has access to some attributes it can assert about them.
SP - Service Provider - This is the end service that will consume Shibb asserted attributes. These are the applications we would refer to as “Shibbolized”
ARP - Attribute Release Policy - fairly complicated policies about what attributes are released for what services, and potentially on a per user basis. These are configured through XML.
WebSSO - this is a rebranding of WebISO. Not sure why, but I like it.
Tags: aegis, aegis usa, arp, attribute release, camp, camp_062, eauthentication, educause, federation, identity management, idp, internet2, luminis, nmi-edit, openid, scott cantor, shibb, shibboleth, single sign on, sp, Sun Identity Suite, sungard, wayf, webiso, websso, xml
Showing More On Your Terminal
January 13, 2006 | 4 Comments
I have a monitor hooked to a FreedBSD system in my office that used to just show a login prompt all day long. Occassionally I’d sit at this machine and use the console, so the monitor was useful, but 99 out of 100 times I’d just SSH to the machine.
I decided to put this monitor to better use by continually outputting some log data to this screen. Specifically I’m outputting LDI synchronization events, which are XML. Initially I was pretty satisfied with this, except for one littel annoyance. XML is bulky, so I could only see one event on the screen at a time. I found that using scroll lock I could scroll back and see old events, but what I really wanted was either a smaller font or more lines.
Enter vidcontrol.
vidcontrol -i mode will show all the modes your display supports, but more importantly, vidcontrol 80x60 will change your terminal from the standard 80×25. In short, you’ll get more than double the number of lines.
More importantly, I won’t have to wade through the man pages next time I forget this command…
Thanks to Erich for the help on solving this one. He found some great docs on vidcontrol and vidfont, whihc I have since lost… However, here is the manpage on vidcontrol.
Tags: bsd, freebsd, ldi, linux, log, logging, monitor, monitoring, terminal, unix, vidcontrol, xml