Prerequisites

• Your own Gitlab server.
• ADFS 2012 R2 or 2016.
• The signing certificate thumbprint of your ADFS server.
• Some basic knowledge about claims.

Configure Gitlab

You have to modify the contents of your gitlab.rb file, usually located in /etc/gitlab/. Most important is that we configure the default ADFS claims to be used. That makes it easier to configure it in ADFS.

# Following settings are needed for omniauth (/saml)
# See https://docs.gitlab.com/ce/integration/saml.html for more information.
gitlab_rails['omniauth_enabled'] = true
gitlab_rails['omniauth_allow_single_sign_on'] = ['saml']
gitlab_rails['omniauth_auto_link_ldap_user'] = true
gitlab_rails['omniauth_auto_link_saml_user'] = true
gitlab_rails['omniauth_block_auto_created_users'] = false

# Configure omniauth the the correct provider.
gitlab_rails['omniauth_providers'] = [
{
  name: 'saml', # This is the internal name of the omniauth provider
  label: 'The button label',
  args: {
    assertion_consumer_service_url: 'https://git.yourdomain.com/users/auth/saml/callback',
    idp_cert_fingerprint: '2c:4f:d3:ce:34:34:8b:80:...', # This is the signing certificate thumbprint
    idp_sso_target_url: 'https://adfs.yourdomain.com/adfs/ls/', 
    idp_slo_target_url: 'https://adfs.yourdomain.com/adfs/ls/',
    issuer: 'http://git.yourdomain.com', # This is the main url of the gitlab installation. (confusing name!)
    name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent',
    attribute_statements: {
      username: ['http://schemas.xmlsoap.org/ws /2005/05/identity/claims/upn'],
      email: ['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress'],
      name: ['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name'],
      first_name: ['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname'],
      last_name: ['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname'],
    }
  }
 }
]
# See https://github.com/omniauth/omniauth-saml#options for options.
# Automatisch redirect naar login scherm, skip this when testing!
# gitlab_rails['omniauth_auto_sign_in_with_provider'] = 'saml'

You’ll have to restart (or maybe reconfigure) gitlab in order to pickup the changes.

Configuring ADFS

Once you have changed the gitlab settings, you’ll be able to add Gitlab as a relying party by importing the metadata. The metadata is available at https://git.yourdomain.com/auth/saml/metadata. So go ahead and add Gitlab as a relying party.

For configuring the claims you can just go ahead and add a new Rule (Send LDAP Attributes as Claims).

• E-Mail-Addresses => E-Mail Address
• Given-Name => Given Name
• Surname => Surname
• Display-Name => Name
• User-Principal-Name => UPN

Then add an additional rule where you convert the UPN to the Name Identifier, add a new rule (Transform an Incoming Claim).

• Rule name: Convert UPN to Name ID
• Incoming claim type: UPN
• Outgoing claim type: Name ID
• Outgoing claim ID format: Persistent Identifier
• Pass through all claim values

All set

If you made it this far, you’re ready to test it out.

Still got any questions? Feel free to contact us.

Voordelen

Wat zijn de voordelen van single-sign-on?

• De gebruiker hoeft maar één wachtwoord te onthouden.
• De gebruiker hoeft maar op één plek zijn wachtwoord in te vullen (en niet op 4 verschillende inlogpagina’s). Je kan gebruikers dus leren dat als het inlogscherm er anders uit ziet dat het waarschijnlijk phishing is.
• Als er een wachtwoord wordt afgekeken (of iemand het post-it blaadje heeft meegenomen) hoeft er maar één account geblokkeerd te worden. Waarschuwing: er zijn gebruikers die overal hetzelfde wachtwoord gebruiken….
• Als beheerder kan je op één plaats instellen of een sterk wachtwoord verplicht is.
• Je kan op één plaats multi-factor-authenticatie implementeren, hierover later meer.

Nadelen

Zijn er dan ook nadelen aan single-sign-on? Eigenlijk is er maar één nadeel, als er een wachtwoord wordt afgekeken heeft de “aanvaller” (lees scholier, hacker of buitenstaander) meteen toegang tot dezelfde systemen als de rechtmatige gebruiker.

Dit nadeel wordt vaak gebruikt als argument om dan maar geen single-sign-on te implementeren.

Hoe werkt het?

Er zijn verschillende manier van single-sign-on maar ze werken allemaal ongeveer hetzelfde.

1. De gebruiker gaat naar de website (/applicatie) die hij/zij wil gebruiken.
   • De website weet waar het inlogscherm zich moet bevinden.
   • De website vraag de gebruiker bij welke organisatie hij/zijn hoort.
2. De website stuurt de gebruiker naar het vertrouwde inlogscherm, met een bepaalde code in het url zodat het inlogscherm weet waar de gebruiker naar toe wil.
3. Op het inlogscherm zijn er 2 mogelijkheden
   1. De gebruiker was al ingelogd (op het inlogscherm of een vertrouwde computer).
   2. De gebruiker was nog niet ingelogd en dient zijn gebruikersnaam en wachtwoord in te typen.
4. De gebruiker is nu ingelogd op het inlogscherm van de organisatie (bedrijf of school) en de single-sign-on server van de organisatie stuurt op een veilige manier bepaalde gegevens van de gebruiker naar de (externe) webapplicatie, zodat deze weet welke gebruiker ervan gebruik wil maken. De externe website krijgt op deze manier nooit het wachtwoord van de gebruiker te zien.

Waarom gebruiken we dit (nog) niet?

Single-sign-on is super handig vanuit het punt van de gebruiker, één keer je wachtwoord intypen en meteen overal toegang hebben. Maar waarom gebruikt nog niet iedereen dit?

• Voor het ondersteunen van single-sign-on moet je als organisatie een server inrichten en beheren, Microsoft biedt hier ADFS voor aan, dit zit in de standaard Windows 2012 R2 / Windows 2016 licentie.
• De (externe) website (of applicatie) moet (bij gebruik van ADFS) SAML2, WS-Federation of OpenID-Connect ondersteunen. Bij het uitzoeken/aanbesteden van externe diensten is het verstandig om dit als eis mee te nemen.
• Het argument van de beheerders, als er een wachtwoord wordt afgekeken hebben ze meteen overal toegang.

Dit laatste argument, hoe zorgen we ervoor dat de gevolgen beperkt blijven als er toch een wachtwoord wordt onderschept? Is eenvoudig op te lossen door het inzetten van multi-factor-authenticatie. En dan blijft eigenlijk alleen de wil over om het inloggen voor alle gebruikers daadwerkelijker makkelijker te maken.

Wij kunnen dan ook elke organisatie adviseren om dit te implementeren, het is namelijk erg gebruiksvriendelijk richting je gebruikers. En mocht je deze klus niet zelf kunnen of willen doen, kijk dan eens hier. Wij bieden dit namelijk aan als een van onze diensten.

Single-sign-on implementeren Neem contact op

Multi-factor-authenticatie

Veiligheid is een punt van aandacht bij het implementeren van single-sign-on. Maar hoe zorg je er nu voor dat iemand die het wachtwoord heeft onderschept daar eigenlijk nog maar weinig aan heeft? Multi-factor-authenticatie betekend dat er niet alleen wordt gekeken naar iets dat de gebruiker weet (zijn wachtwoord), maar ook naar iets dat de gebruiker heeft.

Wat kan een gebruiker hebben, waarmee de veiligheid te verbeteren is?

• Een geregistreerd apparaat, bijvoorbeeld een speciale groep computers uit het bedrijfsnetwerk.
• Een speciaal IP-adres, uit een vooraf gedefinieerde range.
• Een hardware token, dit apparaatje genereert elke keer een andere code die moet worden overgetypt op het inlogscherm.
• Een sms code, na het invullen van je gebruikersnaam en wachtwoord ontvang je een sms met een code die je moet invullen op het inlogscherm.
• Een applicatie op je smartphone die vraagt of je op dit moment probeert in te loggen.
• Een applicatie op je smartphone die elke 30 seconden een andere code toont.

Kortom er zijn tal van mogelijkheden die je zou kunnen gebruiken om het inloggen op (bepaalde) applicaties veiliger te maken. De mate van veiligheid van deze mogelijkheden verschilt natuurlijk.

Hier kan je als organisatie zelf een keuze in maken, voor welke applicatie je welke eisen stelt. Heb je een website met het lesrooster, dan  mag waarschijnlijk iedereen met een gebruikersnaam en wachtwoord die zien. Maar heb je een applicatie met leerling-dossiers, dan wil je waarschijnlijk een van bovenstaande extra maatregelen nemen.

Met onderstaand script kan je heel eenvoudig een licentie (voor bijvoorbeeld Office 365) uitdelen aan alle leden van een security groep. Het is daarbij wel vereist dat deze groep in de cloud is aangemaakt (of daar naartoe wordt gesynchroniseerd). We hebben geprobeerd om per regel uit te leggen wat er gebeurt en daarom zou dit redelijk makkelijk te lezen moeten zijn.

# Install the module (if not yet installed)
# Install-Module AzureAD # you need local admin to install modules....

# First connect to Azure AD
# You'll be asked for your admin credentials
$cred = Get-Credential
Connect-AzureAD -Credential $cred

# Set the username for the user that has the correct license
$username = "[email protected]"

# Find the license of that user
Get-AzureADUserLicenseDetail -ObjectId $username | Format-list

# Set the correct SkuId with one of these methods
[GUID]$sku = (Get-AzureADUserLicenseDetail -ObjectId $username).SkuId
# [GUID]$sku = '78e66a63-337a-4a9a-8959-41c6654dfb56'

# Create a licenses object
$license = New-Object -TypeName Microsoft.Open.AzureAD.Model.AssignedLicense
$license.SkuId = $sku
$licenses = New-Object -TypeName Microsoft.Open.AzureAD.Model.AssignedLicenses
$licenses.AddLicenses = $license

# An individual user can be given a license by using this line
Set-AzureADUserLicense -ObjectId "[email protected]" -AssignedLicenses $licenses
# You might have to set the correct location first
Set-AzureADUser -ObjectId "[email protected]" -UsageLocation NL
# Set wanted location
$location = NL
# Set the location by full groupname
$groupname = "[email protected]"
Get-AzureADGroup -ObjectId $groupname | Get-AzureADGroupMember -All $true | Where-Object -Property UsageLocation -Value $location -ne | Set-AzureADUser -UsageLocation $location
# Set the licenses by full groupname
Get-AzureADGroup -ObjectId $groupname | Get-AzureADGroupMember -All $true | Where-Object -Property AccountEnabled -Value $true -eq | Set-AzureADUserLicense -AssignedLicenses $licenses

# Set the licenses by part of the groupname (BE CAREFULL!!)
$searchQuery = "first_part_of_g"
Get-AzureADGroup -SearchString $searchQuery | Get-AzureADGroupMember -All $true | Where-Object -Property UsageLocation -Value $location -ne | Set-AzureADUser -UsageLocation $location
Get-AzureADGroup -SearchString $searchQuery | Get-AzureADGroupMember -All $true | Where-Object -Property AccountEnabled -Value $true -eq | Set-AzureADUserLicense -AssignedLicenses $licenses

Heb je nog een goede toevoeging voor dit script, laat dan hieronder een reactie achter. Ook als je weet hoe je het benodigde account op een veilige manier kan opslaan.

Mochten jullie als school interesse hebben om het lesrooster te synchroniseren met Office 365, kijk dan eens naar Roostersync.