Feide


Feide has an architecture where one Identity Provider has multiple Authentication Points behind the IdP.  Authentication Points are implemented as LDAPs, and all the LDAP servers are using the same norEdu* schemas (norEduPerson, norEduOrg, norEduOrgUnit) building on  eduPerson which builds on inetOrgPerson. This sounds complicated, but in real life this amounts to minimum technical overhead, as the only changes needed in the local technical infrastructure are

  • adding the norEdu* schema to the existing LDAP (since every single institution has at least one LDAP)
  • regular updates of the LDAP from authoritative sources (student registry, payroll systems, school management systems etc)
  • configuring filters for the information from authoritative sources
  • installing SSL/TLS on their LDAP, and giving Feide the certificate information

The identity management itself is mostly an administrative process, and this is the part of process re-engineering and auditing that takes time.

A university or college or school owner have their own realm. Each realm provisions users to their own LDAP, and the IdP looks at all the realms.

Why, oh why, is this not supported in off-the shelf software?  Are there no mergers in business outside higher education?  It is a simple mechanism that allows for integration of several user groupings, and we know from experience that it works.

In an earlier post on SLO I promised to get back with more information about the usage of single logout, as Feide adds more and more services to the SLO service.  The graph below shows the ratio of Single Log Out (SLO) to Single Sign On (SSO) for the Feide production Moria4 site.  It is interesting to note that the SLO to SSO ratio is increasing (the initial fluttering is due to pre-production testing), and there is a marked jump at the same time as several reliable service providers were added.  A peak at the underlying data indicates that several services have logout ratios above 50%, among these are library databases and exam registration.  SLO to SSO ratio

Even if all services implement SLO, not all services have a good location for the SLO button.  In practice this leads to not all users having access to logout.  Most users still close the browser to log out from a service, or does not log out.  For those who do not log out, the session timeout functions as their logout.  Session timeout in Feide takes several hours, which is a long time compared to BankID where the session lifetime is minutes.

The Moria4 site above went into production April 29, and several major service providers were added in late May.  The overall SSO traffic is shown below.

Single Sign On for Moria4

More information about the technical implementation is available in Andreas’ presentation on SLO from TNC2009

Logout interfaceLogging in is simple.  Getting out is simple, you just close your browser.  Unless you wanted to explicitly log out, or you needed to log out from just one application and keep the other applications working. Another issues is related to closing all browser windows, this sounds easy to do, but can be too difficult for some users.

Andreas implemented a nice user interface for single log out in SimpleSAMLphp, as shown on the right.

A surprising high number of users (8-10%) started using the SLO functionality when this was enabled in March 2009. If this number continues to stay high as we move from pilot in a selected user group to the broader audience in education remains to be seen.

Our main motivation behind the SLO interface was to offer a way to log out from one specific application where the licensing scheme was based on payment per  user logged in at the same time.  This motivated us to find a way to log out from that system, while keeping the other sessions with service providers alive.  If we demanded a global log-out, the end users would loose their work flows in all applications within the single sign on domain.  Not using federated log-out would simply give the user a SSO session in to the application for example at a browser refresh, and this without the user knowing and being able to control the situation.

User testing provided useful feedback, and we ended up with a page as displayed above.  If log-out fails from any application (as it sometimes does with HTTP redirect when a server goes down), this is indicated with a warning sign next to the service.  All successful log-outs are marked with green.  The user is advised to explicitly close all browser windows if log-out fails.

Making the end user aware of what applications he is logged in to, is part of the awareness raising for greater security. On the other hand, we do not want to drown the user in information, because than we end up in the Click-OK-to-continue syndrome.  The minimum information required is the names of the services and some graphic indicators of login/log-out situation.

More information about the technical implementation is available in My thoughts about SLO by Andreas Åkre Solberg, and in the SimpelSAMLphp documentation.

Why are we spending effort on walling off bigger and bigger spaces on the Internet, and giving everyone a federated ID when what we want is more social media: sharing information, participation and communication?  This question was posed today by one of the participants in Det Digitale Trøndelag (e-collaboration for the public sector in Trøndelag).

Why is identity a necessary part of building the social media?  Social media (and web 2.0) is social because we have the ability to share information using different relations and services.  Relations to other people is normally dependent on identity services to function.  Facebook uses the consept of “friends” to select who gets to see your information, where Twitter use the “follow” function to determine what appears on you personal tweet.

The Internet part of life gets bigger and more interactive.  Transcending the passive consumer status requires the ability for both people and computer systems to read, write, collaborate and determine relevance.

People Computer Systems
Read Data import
Write Data export
Collaborate Exchange data, establish secure communications
Discover information Capability negotiation
Determine what is relevant Personalization, authorization
Trust Security

Higher education and research federations are using the eduPerson schema, where eduPersonAffiliation and eduPersonScopedAffiliation is the basic way of handling roles. The only well-defined roles consist of the vocabulary for eduPersonAffiliation, with some local extensions.  Some federations have defined other well-scoped vocabularies for roles in special attributes.  eduPersonAffiliation is used in a large number of applications.

I would like to see some more simple roles for learning, staff duties and high performance computing.  Currently I am trying to gather the information that will make it possible to make some small steps towards semantic interoperability for roles within our community, as requested in a recent report on Strategies for shared administrative services in Norway (Norwegian only) and by several universities.

Learning roles should take up the vocabulary defined in IMS Enterprise, which is used for populating e-learning support systems (Fronter, It’sLearning) for courses: Learner, Instructor, Content Developer, Member, Manager, Mentor, Administrator, TeachingAssistant.  These values are also used in Norwegian Standard NS4170, Person Information Flow in Education (PIFU).  Mappings from the roles in FS, the shared Student Registry are well-defined.

Research roles include project manager, project participant, main author and co-author.  Other research roles may be related to the grid community.  Work on Short Lived Credential Service (SLCS) based on federated login is going to give us more information on the role requirements from the grid community.

Administrative staff comes in the flavors of: finance officers, HR, archivists, IT and student registrars.  All of these groups are present in universities and colleges, and the functions of a staff member is linked to a specific place in the organizational chart.  This should, in theory, make it possible to identify roles and use these roles to limit access to specific services.

Currently the web services seems able to handle information about a single end user, so the roles must be mapped onto each user account (probably in LDAP or such-like).  In addition to this information, there should be restricted meta-information about the groupings/roles themselves available.  And having the roles represented as groups (isMemberOf) in the local LDAPs could be helpful.

Earlier attempts to define semantics for shared roles has failed, mostly due to the inability to define a problem statement.  My problem statement so far:  Define semantics for shared roles that are preventing interoperability or administration of security domains in key IT services for staff administrative services, learning and research in Norway’s higher education.

Still work to do on these issues…  to be continued

Feide‘s latest update of the federated login service includes a major revamping of our consent information. Every user gets splashed with a web page about what information the service requesting the login is demanding, and given the option to opt out before information is transferred. The software behind the consent module in SimpleSAMLphp was developed in WAYF, the Danish higher education federation. Consent user interface

Informed consent is an underpinning of most privacy legislation in Europe, but has been given lip service without real implementation. The two main reasons for this is lack of interest and bad user interfaces. Lack of interest is understandable since the consequences of not having informed consent are ignorable.  Bad user interfaces, where the user is exposed to either legalese or tech-talk in stunning doses, has killed most emerging implementations.

The new Feide login has three steps to login:

  1. Chose where you are from (sticky information, sticks in a cookie)
  2. Write username and password
  3. Consent to information transfer (sticky information, sticks in a database)

Where you are from is remembered for weeks, but you have to supply this information again if you change your computer since the information sticks in a cookie. The information times out over the summer holidays.

Username and password needs to be reentered every session, but gives you Single Sign On between separate services.

Consent to information transfer is stuck in a database, unless you chose not to remember consent. If you chose to remember, the consent may be removed using the consent administration service.

Some users get confused by this new third step in the login process, especially when they are redirected as part of SSO and have not seen the login page for the service they are redirected from. Other users are happy to get presented what happens to they personal information elements on the wild wild web.

Consent administration is a separate service, where you at a glance see all the information requested for transfer by each of the services you have ever logged in to using Feide.

User interface for consent administration

User interface for consent administration

End user approval of the consent service is going to be interesting.

A by-the-book man-in-the-middle attack occurs in three steps:

  1. Gather information about the victim server, to enable a fake server to take over
  2. Take control of the data flow, at either network level (ARP, routing) or domain name (DNS) or application level (firewall, proxy)
  3. Insert fake server and trick end user into connecting

The counter-measures include

  1. Protect victim server: Verify communication with server by using TLS/SSL, restrict secret information about the server (private keys, passwords etc)
  2. Data flow control: surveillance, monitoring with alarms about unusual patterns for all infrastructure components, configuration verification
  3. Fake servers: pop-up warning to end user about certificate inconsistency, train users to recognize danger, Extended Verification certificates

The two first points are mainly about infrastructure and work on this is included in the regular risk and vunerability analysis that are carried out.  The last point includes training end users to recognize danger, and involves working with user interfaces as well as with technology itself.  Regular user interface testing should in my opinion be part of the usual risk analysis for distributed systems.  It would not hurt to include some work on the end user’s risk perception, to the extent that this is known.

Next Page »