An eduroam Sunday in Canada

One aspect of being the eduroam operator in Canada is how to maintain the high quality of service eduroam is known for and respond to issues that may arise before end users encounter them. To do this, CANARIE has taken a proactive stance to monitoring the health and performance characteristics of eduroam in Canada and works with domestic eduroam sites to improve the service or diagnose issues. An offshoot of this investment is being able to better understand how the service is used through the performance monitoring data and feed this information back in to improve on the eduroam environment.

This is not a small undertaking as eduroam interconnects 48 sites across Canada as well as to the international eduroam system of 60 plus countries.

What piqued our interest and this blog post is a particular Sunday in May had higher traffic than traditionally expected, much like a weekday, and we wanted to see if we could find out why.  As we dug into our numbers we visualized the data in a number of dimensions, by time and by location to better depict how eduroam is being used.  It shows how mobile users can be anytime and anywhere when they are connected with CANARIE and CAF.

The Stats

The daily report for Sunday that shows the overall hourly traffic that the Canadian eduroam servers observe.  Traffic is exclusively those who are mobile and not at their home institution and are sign ons, not individual users.  A sign on can be a single user, but from multiple devices or from a single device as they move around.

The graph below shows traffic across Canada on Sunday May 5th, 2013.  The stats behind the line are from our sites across Canada.  The Success line is self explanatory, but a ‘Fail’ entry may be due to a variety of reasons and be very intermittent as shown in the spike just before 4pm below. Being able to identify these is always a work in progress to keep the quality of service as high as possible. This one looks transient and quickly goes away.

Sunday eduroam Stats

The above graph illustrates individual traffic by domain.  We have masked the domains and will focus analyzing stats for the highest line in the graph.

So where are Canadian mobile users benefiting from eduroam?

Short answer: All over the world!
Zooming in on traffic for this one domain and overlaying it on a map we get an idea just how mobile this domain’s users are. Remember this data spans the 24hrs on Sunday.

eduroam-pic2

Here are a few views from other regions around the world for this domain:

eduroam-pic3

Central and northern Europe:

eduroam-pic4

 

Inside Canada

Eastern Canada and North East USA:

eduroam-pic7

Western Canada

eduroam-pic5

Now in the Eastern Ontario area:

eduroam-pic6

Observations

All in all, very interesting just how mobile users are in this one domain. It also drives home the point that being connected is not only important  across Canada, but worldwide and not just Monday to Friday 9-5 either, but 7 days a week, 24×7. You can see this in the first graph at the top of this post as the successful sign ons  never goes to zero even at 4am Eastern  —  somewhere in the world there are people from this domain using their home institution credentials.
While obviously a great benefit for eduroam users to be on wifi around Canada and the world, behind the scenes it allows eduroam site operators to avoid issuing guest accounts and/or  having to running open WiFi access points to support mobile users all the while maintaining the appropriate level of certainty of who is using their network.

I would be remiss if I did not extend the invitation to those not connected to CAF to join and expand the coverage of eduroam even further in Canada. We would love to have you connected!

Postscript

I will be presenting at CANHEIT 2013 in Ottawa on All Things Eduroam as well as our work on simplifying participating with CAF for eduroam and Federated Single Sign On(SSO) in my Leveraging the Cloud to Deliver Identity Services talk. See you there!

Some eduroam improvements behind the Scenes

Things have been quiet as we’ve been heads down working and are ready to share some of our progress. One item the CAF team has been working on is improving the eduroam health monitoring infrastructure behind the scenes. This is in response to intermittent reports where eduroam doesn’t work as well as it should have.  By enhancing the monitoring infrastructure it allows us to better assess how well (or not) eduroam in Canada is performing and identify any improvements that can be made.  This helps maintain the quality of the eduroam service as good as it has been or better as eduroam spreads further across Canada.

What does the end user see?

For the most part, end users experience a reality of either it works or doesn’t and as a rule,  things appear to work  smoothly. This is sometimes deceptive, but unintentionally so.  Some devices mask the number of retries they make attempting to get online and all you may see is the checkmark beside the eduroam SSID indicating you are connected.  What is not seen though are that some devices retry aggressively multiple times anywhere between 5 to hundreds of times in the span of a few minutes to get online. Multiply this by the number of devices you carry (laptop, phone, tablet etc) and maybe a wrong password in one device and you can get a glimpse at what the problem could be if not handled well.

While the end user doesn’t see or realize this is happening under the hood,these transactions are visible at the Canadian eduroam servers — of course only for traffic originating in Canada.  This style of activity is taken into consideration and is part of the monitoring practices and metrics we track.  We don’t always have a lot to go on other than the destination and origin due to the encryption of the traffic but that is enough for us to engage and inform the target sites that something may be going on or has occurred.

Analyzing the Data So Far

With over a million successful monthly sign-ons since November 2012, we’ve had a lot of data to analyze! As a starting point, we are looking at requests that result in a ‘No Reply’ response in our logs at our root Canadian eduroam servers, which would indicate that a participant’s RADIUS server is temporarily offline.

24hr-report

Right now the traffic patterns show a 10% ‘No Reply’ overall rate for RADIUS authentication requests.  These requests appear in spikes like the above graph of 24hr of eduroam traffic. It may be that this is an artifact of the UDP based protocol or potentially how ‘chatty’ mobile devices could be but either way our goal is to understand what it means and how we reduce the problem from current levels and in turn improve the eduroam service.

What Canadian eduroam Sites May See Next

CANARIE will be analyzing log files a few times a week and may reach out to individual eduroam site contacts to clarify anomalies as we encounter them. We know time is precious and diagnosing a transient issue is difficult so if we do contact you we will try and provide a detailed report about the time period in question. We use Splunk, a commercial log analysis tool with our custom reports that can pinpoint the issue and timeframe in question save diagnosis time.  Even with tools like Splunk we still manually assess when to escalate to a site to ensure that it’s worth digging into and appreciate your help to go the ‘last mile’ with your local RADIUS  and network logs.

Dispatches from REFEDS and VAMP2012

Good morning from Utrecht, NL where I am attending as CANARIE’s CAF representative for REFEDS & VAMP2012

I’ve found that this September is an inflection point for change; back to school kicks in, summer holidays recharge the batteries and give a chance to step back and take stock. To this end, I’m going to experiment with a  more brief communication model with this blog.  There may be the occasional essay like post because complicated topics need their due depth, but I would rather have more frequent postings to avoid the TL;DR (Too Long; Didn’t read) and see which ones to go deep on as people express an interest in them.

Why REFEDS?

Research and Education FEDerations is one of the few locations dedicated to the interests of  CAF and our peers.  It is also a forum for advancing Federated Identity topics and collaborating on workplans to the benefit of multiple federations.  One topic that has been incubating in the REFEDS environment are recommendations for Service Providers for Federated ID sign on and discovery which are based in part on a NISO Espresso Report.  An interested and comprehensive document at 35 pages. More to come on this front soon.

As the REFEDS meeting progresses more will be posted to this blog entry.

In the mean time, I would like to point you to the 2 day VAMP2012 agenda and encourage you to post comments or questions that you would like to hear me bring forward.

Browserless Federated SignOn Techniques Contrasted: Shibboleth/ECP and ABFAB/Moonshot

One of the key puzzle pieces for federated ID is how to deal with sign on outside the browser. When you peek behind the curtain of the web  you will see tools like SSH and SCP and jobs running on machines pushing content everywhere and people signing in to accomplish tasks ill suited for the web.  In other areas you’ll see people wanting to use their ID to sign into a cloud application on their smartphone (like mail) or a specialized application on their desktop (think Google Earth).

We want to mask some of the complexity of using a Federated ID behind the curtain as much as we can and only reveal what is REALLY needed to get the job done.  In this posting we’ll be exploring two candidate technologies to do this.

WARNING! Some technical content ahead!    Ok, this posting  may be a bit of a technical read, but I’ve tried to keep the acronyms to a minimum.  I am also assuming that you know a bit about Single Sign On techniques and have slightly more than a passing familiarity with Shibboleth and SAML.

So put on your gear for something beyond a shallow dive, but not the full deep dive it could be, I don’t think you’ll get the bends but if the comments drag us into that territory don’t blame me 🙂

The Contenders

We are going to take a look at two approaches to non web sign on; Shibboleth with the ECP (Enhanced Client or Proxy) plugin and the IETF’s ABFAB (Application Bridging for Federated Access Beyond web) that was formally known as Project Moonshot.  Both techniques have their merits and drawbacks.  I hope that  by offering this comparison I can help identify some of the things to think about and hear back from others about how on target (or not) I am with the analysis.

Non Web Federated ID Use Cases

Use cases take the shape of many things:

  • IMAP mail access for your smartphone
  • plain SSH/SFTP for secure shell access
  • A rich or ‘fat’ client that leverages local graphic and compute capabilities.
  • Insert your clever outside the browser use of id/passwords.

Use Case: Mail in the Cloud

This is/was slide 51 from the Live@edu slide deck from one of their TechNet in late 2010 (credit: Microsoft).  It illustrates the use of the Microsoft Federation Gateway communicating with Shib ECP for authentication.  The end users offers their userid scoped with their domain (e.g. joe@my-university.ca) and the ‘hint’ of the domain allows the gateway component to direct the authentication request to the appropriate ECP enabled interface.  This hint is not part of the SAML protocol at all, but a function of how the cloud service provider will route the request it receives to the right provider. The password DOES transit the cloud  so it is up to the Identity Provider to have sufficient assurance from the vendor that the right steps are taken (e.g. IMAPS, safe transit within the cloud etc).

The reply by the Shibboleth IdP via a reverse SOAP call (PAOS, yes soap written in reverse) and carries a special identifier for the Live@EDU service: PersistentID.  This value is special to the cloud mail service as it links the person to their mailbox.  My understanding from IdPs participating in this space is that the PersistentID is generated upon account creation in the institutions person registry.It is just an attribute passed over the wire instead of a dynamically computed attribute like eduPersonTargetedID. It is also BASE32 encoded which eduPersonTargetID is not.

Use Case: Federation Aware Rich Desktop Client

Screenshots of some of the OpenJump documentation that uses SAML. OpenJump deals with the discovery issue by having you as the user enter the Metadata URL into the actual application.  Good? Bad?  Well, you judge, but if you say bad, help us understand how you would do it to minimize the user managed discovery aspect? Hand waves don’t cut it, please be specific…

Key Considerations – Tipping Point Concerns

You can argue that we need to look at many facets of the conversation, but I contend that there exists tipping point ones you need to pay attention to and are the key drivers — these are ‘the who’ and ‘the what’. Once you wrestle those to the ground, the rest will follow when going through a comparison on what to use in your situation.

The Who

‘The who’ is your audience of users and the important question to ask about them is ‘How diverse a group are they?’  If you can influence/control the diversity as in keep them all originating from the same bucket, then this may work to your advantage — more on this in a moment.  If you can’t and are talking about a diverse set of users originating from many identity providers then this is important too.  In either case, there will always be an identity provider of last resort to capture the corner cases and our goal is to minimize this set as much as possible.

The What

‘The what’ is what are you trying to deliver or improve?  Are you trying to allow a smartphone or tablet access to their email or are you trying to allow SSH/SFTP access to unix boxen under your control?  Are you trying to do both?  Your endpoints you want to serve are going to influence your selection.

Comparing and Contrasting

The table below highlights some of the comparison points to be considered:

Shibboleth+ECP Moonshot/ABFAB
Password Treatment Userid/Password pair seen & transits outside classic Shibboleth infrastructure boundaries Userid/Password seen @ endpoint & transits through RADIUS infrastructure via SSL tunnel
Home Institution Discovery Somehow preconfigured either via user or by static configuration in proxy & proxy under an infrastructure providers control Userid contains hint to institution so it is present in credential and implicitly discoverable on usage
(e.g. <id>@realm.ca)
Attribute Exchange Exchanged via SAML2, aggregated via standard Shibboleth fashion (DB/LDAP/static values etc) Exposed via GSS API, delivered via RADIUS pack/unpack technique, aggregated from many potential sources
‘Breadth’ of accounts ECP configuration or end user intervention drives breadth of coverage If RADIUS uses eduroam, entire set of  federation accounts are available
Environment Used in Mobile devices, IMAP clients, very targeted and controlled infrastructures. Unix machines with a preconfigured Id Provider. Unix shell environments, rich clients, anywhere that the GSS-API exists.

There are more, but to me these are the big ones.  I’m sure there are readers out there that have thoughts, so please share them and I’ll see if they fit in.

Conclusions…for now

If you were looking for me to declare one method over the other, I’m sorry to disappoint — the answer is of course it depends.  It will depend on how you respond to  ‘the who’ and ‘the what’ and then feed that into the calculation of Total Cost of Ownership (TCO) of the approach you choose.

Some of these things are going to be intangibles too, like ‘are you staffed with the right skills?’ and ‘how many calls to the helpdesk can you avoid?’.  I think anyone going through the decision process on deploying one or the other or even both needs to think about the big picture topics.

I accept that this comparison is incomplete but I believe it to be complete enough for the purpose of kick starting a dialog about it. I look forward to the comments and emails to see how well my position holds…

What could the open wireless movement learn from eduroam?

Prologue:

Welcome to my first formal blog posting.  I’ve resisted for years but recently have been getting more and more involved online and have found that blogging is the instrument of choice to respond to and propagate your personal perspective online.  Participating in the blogosphere reminds me of Cory Doctorow’s take on Social Capital so if I’m going to get in on it, I might as well jump in with both feet.  Let the fun and games begin and I hope I provoke some interesting discussion because isn’t that what blogging is all about?  Thanks for stopping by and I hope you come back for more. Now on with the show…

What Could the Open Wireless Movement Learn from Eduroam?

As I was reading the Electronic Frontier Foundation (EFF) article bemoaning the loss of open access points  across the land I was struck by how closely it tracked the final chase scene  in Ferris Bueller’s Day Off. It’s the one where Ferris is running home but going through people’s back yards as the quick way to get home.  If you are looking for your dose of 80s flashback, here’s the clip

That’s what I think using someones access point uninvited is like…a little exciting, but really crosses into  someones private space (that’s why people build fences, right?) but the shortcut accomplishes your goal at the sacrifice of someones privacy and rights.   As a scene in the movie, it’s great, Ferris gets home but is it really like that in reality? Are open wireless points free game for those who walk by?  As enticing as it is, the risk of transiting someone’s wi-fi ranks up there with don’t talk to strangers and don’t hitchhike: you never know what trouble you are going to get into.

What caught my eye though was the exclamation of “We need WiFi that is open and encrypted at the same time!” and immediately thought of the eduroam service that is part of the Canadian Access Federation .  How does this let you get online? If your institution participates with eduroam there are two main elements.  Allowing access to other eduroam participants and in return you have access to the others participants network.  To do this, you need to have an 802.1x ready wi-fi network and RADIUS as an available technology to support the eduroam SSID.  To use the service you connect with your network_id@your_institution_here.com and you are signed in through the use of chained RADIUS proxy servers.  The simplicity of this is that ANYWHERE you see eduroam, the experience is the same.  In fact, in most cases, you will have signed in automatically  anytime you open your laptop or even walk by with your smartphone, it will connect and you are online.  This has happened to me numerous times.  My favorite was when arriving at the Internet2 spring members meeting hotel and not even checked in at 11pm at night, my phone was already online with eduroam.  No fuss no muss, it just works.

So how prevalent is this in Canada?  Well at the time of writing the AUCC folks  say there are 95 universities registered and 27 of them or 28%  are participating in the Canadian Access Federation which operate the Canadian eduroam presence. Europe coverage is even higher.

In the US there are approximately the same number of sites live (27 according to the map at the time of writing) and another 20 or so more either interested or actively testing out of thousands of universities.  It is hard to explain why the uptake is not as big as Canada or elsewhere.  It can have something to do with being 802.1x ready or maybe it is just not rated high enough priority.  It’s hard to say.

Membership has its privileges.

With eduroam, reciprocity is a big part of the service and has a lot of benefits.  The active Ids inyour system have the ability to roam to other institutions but when someone comes to yours, you don’t have to provision them to get on the network. Opening the laptop really equates to getting online and there’s nothing more satisfying to a traveller that to being able to get online without having to follow some 7 and a half step process to signing in. I was recently at the TERENA conference which had great eduroam coverage and never used my termporary id.  The TERENA conference had 500+ people, 800+ devices connected via eduroam (one person has both a laptop and smartphone/ipad) and had >10,000 authentications over 5 days.

TERENA Badge with temporary userid

At a recent TERENA conference, hundreds of attendees used eduroam and their home credentials and could ignore the temporary userid/password. 

What about security you ask? Eduroam uses 802.1x and WPA2 protocols and your credential is verified at the home institution.  As for what the acceptable use policies (AUPs) are, as the visitor your are expected to abide by your home institutions and the one in which you are a visitor to.  It is all authenticated using your identity so transiting the network is permitted, but not anonymously.

So can just anyone sign up to be on eduroam?  In short, no.  it is geared to higher education institutions and there is a reciprocity balance to be struck.  It is plausible that if one location were to not participate according to the community’s expectations that branch (aka country root server) could be orphaned from the eduroam trust-framework.

Coming full circle, what does this mean to the EFF plea for technology? Is eduroam for them?  Possibly, but unlikely.  Whoever implements wouldn’t even come close to meeting eligibility and then there’s this hard question to answer of whose password store to authenticate against.  I can see the eduroam technique being duplicated much like the dynamic DNS folks who are now found in the actual routers firmware.  So, in theory, you could enable this  ‘feature at your convenience as a personal decision to contribute bandwidth to the common good’.  There are still a bunch of challenges to overcome to meet the EFF free wifi service: administration, findability, getting the word out, does it violate your AUP with your internet provider all come to mind. At the end of the day though it needs to be ubiquitous,  something that works without too much fuss, and is straightforward  for both the enduser and the access point maintainer — kind of like eduroam 😉