Institutions must retain control of the security level of the linked services. They determine session duration for each service. A balance must be found between user friendliness (Single sign-on) and security. This blog describes how session duration works in the SURFconext authentication infrastructure.
Het jaar is bijna ten einde. Tijd om terug te blikken en je te beseffen welke dingen je eigenlijk hebt laten liggen. Zo onder andere het verslag van de SIG bijeenkomst "De summatieve toets overboord". Met het schaamrood op mijn oren dan toch maar posten voor dat 2015 voorbij is.
Dat SURFconext met behulp van het SAML-protocol zorgt voor authenticatie en daarmee antwoord geeft op de vraag ‘wie is de ingelogde gebruiker’, dat mag als bekend verondersteld worden. Dat het inloggen bij de instelling zelf plaats vindt en dat SURFconext de Single Sign On voor de gebruiker verzorgt, weten de meeste van ons ook. Maar hoe kun je als instelling en dienstaanbieder bepalen wat die ingelogde gebruiker vervolgens mag doen? Dat is stap twee, dat is autorisatie.
The Qualys SSLLabs SSL server test is a site that allows you to verify whether your https server is configured correctly. I’m not aware of any web server software that ships with defaults that can’t be improved. Test your site! The remainder of this blog post consists of configuration snippets for popular UNIX web servers (Apache, nginx, lighttpd) to improve the SSL Labs rating. As with all code snippets online, don’t use these without looking up each directive to see what it does.
Over the past years, SURF put a lot of effort in sharing knowledge on sustainability within the SURF community. Four years ago we started working on this topic and since then we’ve managed to build a Green ICT community, the Green ICT Special Interest Group (SIG), of ~400 members from Dutch Higher Education. In collaboration with this SIG, we organised many meetings and shared a lot of best practices on Green ICT. I thought it would make sense to look back and give an overview of what knowledge and experiences have been shared in the community.
Iedereen heeft tegenwoordig internet thuis. Tel zelf maar eens hoeveel apparaten je thuis hebt die van je internetverbinding gebruik maken. Computer, laptop, smartphone, tablet, tv, camera en ga zo maar door. Om die reden heeft vrijwel iedereen thuis tegenwoordig ook een router. Vaak zit de router geïntegreerd in je (kabel)modem, soms is het een apart kastje. De router maakt het mogelijk dat meerdere apparaten de internetverbinding gelijktijdig kunnen gebruiken. Erg nuttig natuurlijk.
OAuth: wat is het en hoe zet ik het in?
Steeds vaker krijgt SURFnet de vraag van een instelling hoe je op een veilige manier een backend-datastore kan ontsluiten voor de buitenwereld. Zolang het gaat om één vertrouwde partij die toegang moet krijgen tot een dataset is dit niet zo’n probleem: wissel een gebruikersnaam en wachtwoord uit, en geef die partij met deze credentials over een beveiligde https-verbinding toegang tot de betreffende data.
More and more institutions are asking SURFnet how to open up a back-end data store to the general public. If there is only one trusted party requiring access to a data set, this is no major problem: simply provide the relevant party with a username and password and they can use these credentials to gain access to the data via a secure https:// connection.
“Every solution to every problem is simple. It’s the distance between the two where the mystery lies.” ― Derek Landy, Skulduggery Pleasant After my first blog on how to make logging out possible for a single service within the SURFconext platform, we got some feedback on the proposed solution:
nice job, this works for us
we don’t like this solution, because it’s not single sign-out
will there be a ‘real solution’ for the single sign-out problem instead of this ‘work around’?
In a previous post, I wrote about the use of so called “rich” or “enhanced” clients in a Web SSO federation like SURFconext. The message I was trying to get across was primarily that the problems encountered using rich clients in a federation are not caused by the fact that federations do not support rich clients, but rich clients do not support federation (any federation – they simply assume users authenticate using a username and a password).
