Luminis Consulting
July 15, 2007 | 1 Comment
I’ve been serving as the portal administrator at Plymouth State University since 2003. I headed their conversion from Campus Pipeline to Luminis III.2 in 2004. On May 28th we were (most likely) the first institution to deploy Luminis IV in production.
During this time, one of the most satisfying aspects of my job has been talking with other schools. It has often been my pleasure to talk with schools as they first start working with Luminis, or are doing an upgrade, or are just struggling with something new they would like to do with the platform.
Out of one of these conversations I was fortunate enough to establish a more in depth relationship with the University of San Diego. This eventually turned into a consulting engagement which I enjoyed immensely. I was able to help them get their newly hired portal administrator up to speed as well as assist in a number of small modifications and customizations. It also gave me the chance to visit their beautiful campus.
SunGardHE offers a number of options for consulting engagements, but they are very busy. It can often be difficult to get someone, especially for small things, and more challenging if you want them quickly. This is where I can offer my services as a Luminis Consultant.
To highlight my qualifications a bit more, I have presented on Luminis a number of times: LDI Implementation Case Study at PSU at Summit 2005, Implement and Deploy Banner Channels (top five Summit 2006 presentation), LDI Implementation Tips and Tricks, Alumni are Coming and Drag and Drop Channels/Statistics Gathering (Developers Lounge) at Summit 2006, Implement and Deploy Banner Channels and Extending SSO with CAS at Summit 2007, and more!
As always, I’m happy to talk with any school about any Luminis related topic, if however, you are looking for more than a couple conversations, I am available for consulting.
Tags: banner, campus pipeline, cas, channels, consultant, consulting, higher ed, higher education, integration, ldi, luminis, resume, single sign on, sso, summit, sungard, sungardhe, yalecas
Summit 2007 Presentation Proposals
October 11, 2006 | 1 Comment
It’s that time of year again. I’ve updated my bio and tweaked a few of the proposals I’ve submitted in previous years. I’m submitting fewer this year than past years as many of my responsibilities in the past year have swayed away from Luminis, reducing it’s core status in my workload.
My Title: Portal Administrator and Senior Web Developer
My Bio:
Zach Tirrell is from Plymouth State University in northern New Hampshire. Zach is both portal administrator and senior web developer for the institution. The main areas of his concentration revolve around integrating systems and identity management, Luminis has become a perfect enabler of this. He is often looking to get just a bit more out of Luminis than what is delivered. In the past couple years Zach has become increasingly involved with Summit events. At Summit 2005, Zach presented “LDI Implementation Tips and Tricks”. This presentation was repeated at Summit 2006 as well as a new presentation, “Implement and Deploy Banner Channels”, which was voted in the top 5 by attending reviewers. While at Summit 2006, Zach also co-presented “Alumni Are Coming! Luminis ROI”. Finally, he hosted an informal session in the Luminis Developer’s Lounge where he covered statistics tracking and drag and drop channels within Luminis.
Implement and Deploy Banner Channels
Banner 7 comes with a huge pile of exciting new channels. These channels greatly leverage the relationship between Luminis and Banner, however, implementation is complicated and deployment even more so. Banner channels are fantastic, but they need to be rolled out carefully. Plymouth State University has already run this gauntlet, come hear some of the concerns and pitfalls so you can avoid them yourself.
This is a repeat from last year
Collecting Luminis Statistics
By leveraging the underlying UPortal infrastructure, learn how to take advantage of RDBMSStatsRecorder to generate detailed numbers on who is logging in, logging out, how often, and by role. These numbers are supplemented with other third party statistic tracking utilities. You can then use these numbers to better understand how effective your portal strategy is. Tracking user adoption and growth over time becomes essential to decision making about the portal.
Extending SSO - CAS in Luminis
One of the most common WebISO solutions is the Central Authentication Service (CAS) developed by Yale. In Luminis III.2 CAS became available as an installable module. Learn how to get CAS installed, configured, and where it might fit in your organization. See how Plymouth State University has leveraged the phpCAS libraries to CAS’ify all their internally developed PHP web applications as well as a few third-party ones. What’s best, it only takes a couple lines of code!
This topic is for technical audiences
Tags: banner, banner channels, cas, channel, channels, luminis, portal, portal administrator, RDBMSStatsRecorder, single sign on, sso, summit, sungard, sungardhe, web developer, yalecas
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
Shibboleth For AuthZ
June 27, 2006 | 1 Comment
I had the opportunity to spend a fair amount of time discussing Shibboleth with Vishal Goenka and Josh Horner while I was at Summit 2006 in Orlando. I wanted to know about the support for Shibboleth that was supposed to be coming in a future version of Luminis and a bit about how it will work. During this discussion it became clear to me that Shibboleth’s core ability for attribute release allows applications to get the information they need to make authorization (authZ) decisions.
Until this point I had only though of Shibb as a solution for inter-organizational web-based single-sign on (Federated SSO or WebISO or WebSSO). I knew I could use Shibboleth internally to serve as my WebSSO, but we already have a hugely successful implementation of CAS in our environment. Additionally I haven’t been able to point at a killer application of the federated WebSSO ability. I knew this driver would be coming, but without immediate demand I was luke warm on Shibboleth.
However, the ability to use Shibboleth internally as a central authority for attribute release and in turn a consistent way of doing centralized AuthZ is a gigantically huge win for us. No longer will every homegrown application need to establish it’s own authorization layer with associated interfaces for maintaining that data. Now I have a serious driver for getting Shibboleth in our environment as soon as possible.
So that’s the lead-in to why Ted Wisniewski, Ken Kochien, and I are attending CAMP Shibboleth: Enabling Campus and Federated Single Sign-On.
Tags: authentication, authorization, camp_062, federated, federation, josh horner, shibb, shibboleth, single sign on, sso, summit, vishal goenka, webiso, websso
Web Initial Sign-on (WebISO)
March 8, 2006 | 6 Comments
Web initial sign-on or WebISO is a term defined by Internet2 as a system
designed to allow users, with standard web browsers, to authenticate to web-based services across many web servers, using a standard, typically username/password-based central authentication service.
They created the definition, but that doesn’t mean I need to like it… I’d like to propose an alternate working definition:
A single point for web based authentication which provides SSO across multiple systems and services.
I think that could be word-smithed further to really get it nice and concise. Please comment any recommendations you have on this.
What excites me about WebISO solutions is their fantastic ability to deep link systems and services. Users can bookmark or share URLs and when someone accesses these systems and services they will be required to provide credentials and then be directed through to what they need. This also sets up applications in a loosly coupled structure ideal for changing individual services without affecting others.
The drawback of this approach (when compared against a monolithic portal application) is how there is generally not a single welcome screen presented to users after authenticating. This loss of a “funnel” approach can cause weaknesses in communication and a perceived loss of control in your user population. Another potential area for weakness is providing a directory of services and ways for users to find what they need initially.
For those not familiar, a couple examples of real life WebISO tools would be: CAS (now JA-SIG as opposed to Yale), Pubcookie, WebAuth (from Duke), Shibboleth, and more.
Tags: "central authentication service", "web initial sign-on", authentication, cas, definition, duke, federation, identity, identity management, single sign on, sso, webauth, webiso, yale, yale cas
Mishmash of Acronyms
August 29, 2005 | 5 Comments
While reading technical documentation today Jon and I busted a gut when we read:
“You can set the LDAP authentication process to use Single Socket Layer (SSL).”
I assume this is some tech writers confusion between Secure Socket Layer (SSL) and Single Sign-On (SSO).
Tags: definition, secure socket layer, single sign on, single socket layer, SSL, sso
Single Sign-Out and Session Management
August 10, 2005 | 6 Comments
When dealing with portals we all get very excited about single sign-on (SSO), but I think we often forget single sign-out or overall session management. The end user really gets the main visual benefit from SSO, so this is what I find myself concentrating on. Yet, if somehow connections to external systems are not addressed when a user logs out, you have a potential security problem.
So, the apparently easy solution is to set things up so all sessions on externally connected systems are destroyed when a user logs out. But what if the user wants one of the external systems open? Personally I think that one is easy too, they learn from experience that all connected systems are logged out.
But, what if they don’t explicitly log out, but rather their session expires from inactivity? You certainly don’t want to log someone out of an external system when they might in fact be active in that external system. This leads to the need to be able to make a call which checks with the external system to see if a user is still active in that system. Then the portal can extend its timeout to wait for the external system.
In a perfect world, an external system could log a user out on demand and could also return some sort of last activity for the user in their system. We don’t live in a perfect world. Very few systems are likely to understand how to do these two things straight out of the box. This leaves us trying to find some reasonable middle ground on an application by application basis.When we consider all these things and determine a way to accomplish this, we are no longer talking about single sign-out but complete session management. Just logging someone out is single sign-out, logging someone out conditionally and handling timeouts intelligently is session management. Obviously a well integrated external system will employ session management.
In our environment we have recently been opting for YaleCAS (or just CAS) as a solution to integrate all homegrown external systems. The phpCAS library we use does not do session management appropriately. Luckily we should be able to modify it to make this all work out.
For other systems we use Campus Pipeline Integration Protocol (CPIP). CPIP is far more complex that CAS, but does allow for complete session management. So for now, we need to use CPIP for important, secure apps, and be aware of the limitations of CAS.
Tags: authentication, authn, cas, cpip, identity management, phpcas, security, session management, single sign on, single sign out, sso, yalecas