OpenID Connect 3: Slack can be the identity hub of small organizations

(Technically, this is a blogpost about Oauth2 and not OpenID Connect)

Are you using Slack as a central communication tool? Did you know that you can also use it as your identity provider for other apps you make or buy?

For informal organizations like user groups and volunteer based conferences, Slack is perhaps already your communication hub. This means that the information you have about your users here is as good as you have anywhere. Access to private channels is often well managed as you don’t want random people in your limited conversations.

For many organizations, especially small ones, Slack may be the best option for authenticating your users on other applications. Unlike Google or other social identity providers, you can control who is a member of your Slack team, you can audit and confirm their profile information and you can restrict which channels they can access. The channel membership is a nice fit for application privileges, so you can say things like “this application can only be used by Slack users on the private channel #admin”

Slack implements Oauth2, which is a subset of OpenID Connect. This means that once you have the user’s access token, you have to make a Slack specific API call to get the user profile and other information, like their list of channels. So there is slightly more custom integration code than for full OpenID Connect providers.

For organization that already have a well established Slack team and no other identity manager in use (such as Active Directory), Slack may be your best source of trust for other applications. You can integrate with it using the standard Oauth2 protocol.

You can start your journey at my Boosterconf workshop in Bergen March 14th. https://2019.boosterconf.no/

Posted in English, Identity | Leave a comment

OpenID Connect 2: Why I ❤ ID-porten

The advantage of OpenID Connect is the fact that it’s standardized and widely adopted. This means that a library or tool designed to work with, e.g. Google accounts, can easily be adopted to work with e.g. Microsoft’s Active Directory or the Norwegian national ID provider ID-porten.

Different Identity providers can support different levels of trust between you and your users.

In my next few blogposts, I will explore different OpenID Connect providers and what they can offer you as an application developer.

Norway’s national Identity Provider

The advantages of using ID porten as an identity provider are considerable, but it comes with limitations as well. ID-porten is the identify provider supplied by the Norwegian government to all residents of Norway. It is (almost) fully compliant with OpenID Connect and is compatible with most tools and libraries.

When your user is authenticated with ID-porten, your application receives their national identification number (fødselsnummer eller d-nummer). This identity is generally safeguarded by two factor authentication and the user has been validated by personally showing their identification papers in a bank or police office. You can be very certain of the user’s identify.

The limitation is that even though you know the user’s identification number, you know very little about the user. You have to be authorized to use the national population register and do the lookup yourself to get their name and address. And even then, you don’t know what organizations the user is associated with and what authorization they have there. (This limitation is natural, considering the scope of responsibility of ID-porten)

So the dilemma is that you can be quite sure of who the user is, but you have no idea who they user is. 😂

(Some of this information is available in other national registers and as time goes by, it may be more accessible)

Furthermore, even though you know who your user is, you don’t know if you can trust them or if they are a crook. Most convinced criminals of course retain their right to use online banking and naturally they have ID-porten access. And that’s the way I think we should treat people, even those who have messed up in their lives.

Getting started with ID-porten is a bit harder than for other OpenID Connect providers, but this is mostly administration. First, not all applications are authorized to use it, of course, so you must contact Difi to get access. Secondly, ID-porten is very limited in terms for self service of application administration, so getting client credentials also involved soon emailing.

But once you have your application credentials, integrating with ID-porten is just as simple as any other OpenID Connect provider. As a matter of fact, I’ve made apps that work with Google accounts and re-targeted them to ID-porten with only changes to credentials.

Difi’s OpenID implementation is impressively accurate and robust, but there are still some issues you may run into in mobile app scenarios. (In technical parlance, response_mode=fragment doesn’t support response_type=code without a client secret, which is the easiest secure option for apps)

If you are providing services to Norwegians on behalf of local or state government, ID-porten is your mandatory identity provider. And you can use existing knowledge and tools for OpenID Connect to do so.

You can start your journey at my Javabin talk in Oslo this Wednesday. https://www.meetup.com/javaBin/events/258573600/

Posted in English, Identity | Leave a comment

OpenID Connect 1: Microsoft Azure Active Directory

The advantage of OpenID Connect is the fact that it’s standardized and widely adopted. This means that a library or tool designed to work with, e.g. Google accounts, can easily be adopted to work with e.g. Microsoft’s Active Directory or the Norwegian national ID provider ID-porten.

Different Identity providers can support different levels of trust between you and your users.

The protocol is perceived with an air of mystery by many developers, but it’s surprisingly simple to master. As a developer, you owe yourself and your users to play with OpenID Connect before you ever implement a username+password.

You can start your journey into OpenID Connect at my JavaBin presentation this Wednesday, or my workshop at Boosterconf in Bergen.

In my next few blogposts, I will explore different OpenID Connect providers and what they can offer you as an application developer.

Why Microsoft Azure Active Directory can enable cross-organization cooperation

The main advantage of using Microsoft’s Active Directory as an OpenID Connect provider is that you can validate your users’ association with specific organizations, whether it’s your own organization or one of your customers or suppliers.

While an identity provider like Google accounts or Facebook will supply the name of the user, this information is not at all validated. Just because a Google user is registered with the name “Johannes Brodwall”, there is no way of knowing if this is truly their name. But if you get the same name from Sopra Steria’s active directory, you can be a lot more confident.

Fingerprint

Similarly, end user Identity providers like Google and Facebook can validate that a user had an @soprasteria.com address at some point in time. But when the same claim comes from active directory, you know that this email address was still active at the time of the authentication. Again a much more powerful claim.

Your trust is limited to your knowledge of the users organization, of course. The first time a user arrives from an unknown organization (“tenant” in active directory terminology) you basically know nothing about the organization and the user. Anyone can register an active directory with email addresses that resemble a legitimate organization.

A common misconception is that an administrator of the user’s organization must be involved in order to integrate with an active directory. This is not the case. Anyone can make an application registration that can authenticate users from any active directory. (This used to be called “multi tenant applications”, but Microsoft seems to be smoothing out a lot of the difference between multi tenant and single tenant apps now). But the user will be asked if they consent to your app getting their name, email etc.

The full power of active directory can be unleashed for organizations where the administrator gets involved. If you make an app that e.g. Sopra Steria wants to use officially, an administrator at Sopra Steria can authorize your app to get user details without explicit individual consent and can also authorize your app to receive information about users’ roles and groups. And the administrator can require their users to use Multi-factor authentication for your app and even audit user logins from their organization to your app.

This means that your active directory application will have to deal with both unknown organizations, known organizations with default configuration and organization where an administrator at the organization have set up your app.

Active Directory gives considerable power out of the box and if you’re willing to deal with the complexity, you can get even more.

And all it requires from the developer is to integrate with the fully standard compliant OpenID Connect protocol. This is as easy for Java developers as for .NET developers.

Stay tuned for my upcoming articles about ID-porten and Slack as ID-providers.

Posted in English, Identity | Leave a comment

We’re not good enough – and that’s okay (Norwegian)

This Norwegian language blog post summarizes my talk at Oslo Agile Meetup in the beginning of October.

Jeg tror ingen egentlig vet hvordan de skal få til bra utviklingsprosjektet. Selv når vi lykkes så er det veldig mye flaks. De fleste av oss tror vi kunne gjort mye bedre. For de fleste av oss holder tilstanden til kodebasen oss tilbake fra det vi synes vi burde ha fått til.

Vi har lært en del ting om hva som i teorien skal være løsning:

  • Clean code skal være løsningen. Dersom vi bare hadde brukt de riktige patterns, prinsipper og teknikker så hadde alt vært bra.
  • Software craftsmanship – eller håndverksånd – skal være løsningen. Dersom vi bare hever lista for oss selv som fagfolk så hadde alt vært bra.
  • Funksjonell kontroll skal være løsningen. Hadde vil bare hatt en dyktig produkteier (fagfolk!) og en ryddig produktkø så hadde alt vært bra.

Men det er jo ikke sant.

  • Selv om alle er enige om a koden skal være god, så er vi veldig uenige om hva som er god kode. Spesielt koden andre skriver. Mange team har stille eller støyende uenigheter om koden skal være slik eller sånn.
  • Jeg programmerer som en adspredelse i stedet for å spille data eller se på serier. Det er veldig praktisk for meg at det å trene på faget er verdsatt; MEN DET BURDE IKKE VÆRE EN FORVENTNING for at man skal kunne være stolt av jobben.
  • Og det vi driver med er ofte ikke så viktig for den store verden. Det er ikke verdt å tape familietid eller søvn over. Noen ganger kan det være direkte skadelig. Vi skal ta oss i akt og huske at et av de eldste informasjonssystemene var det Dehomag leverte til Nazistene for å drive konsentrasjonsleire. Oppgaver som er verdt å gjøre følger ikke fra funksjonelle beskrivelser

Så hva kan man gjøre, da?

  • For å få en kodebase med mindre hindringer er det viktigste skrittet at utviklerne snakker mer om koden og at man lærer seg å være ydmyk. Spesielt vi mannfolka må bli flinkere til å si “jeg tok feil”. Og det krever trening! Og parprogrammering funker!
  • Vi må lære oss å begrense oss selv. Den viktigste måten jeg har fått opp farten på er ved å gå saktere – spesifikt ved at hele teamet fokuserer på ÉN oppgave om gangen. Dette kalles gjerne swarming. Som team: Bli ferdig med én ting og gå til neste i stedet for å starte på enda flere ting.
  • Til slutt må vi lære oss å si stopp. De fleste organisasjoner mangler mekanismer for å oppdage og handle dersom man driver med tull. De fleste personer har problemer med å innse at man løper et tapende løp. Det aller viktigste er på det personlige plan: Ikke forbli et sted der kulturen er dårlig og hvor folk ikke er snille med hverandre.

Jeg vet ikke hva som skal til for å lykkes, men jeg vet noen måter vi alltid tabber oss ut på: Jeg vet det er vanskelig å si “jeg tok feil”; jeg vet det er vanskelig å si “la oss bli ferdig med dette før vi starter på noe nytt”; jeg vet det er vanskelig å si “nok er nok”. Disse tingene er hva jeg vil bli flinkere til.

Posted in Extreme Programming, Norsk, Pair programming, Software Development | Leave a comment

Dirty Code Monday!