How to get away with enterprise software development

0 – YAGNI

Before we even write the first line of code, remember that not doing something at all is occasionally a valid option. The YAGNI principle may be applied to various aspects of software development projects. Can we use an existing library for Task X? Was feature Y really part of the specification provided by the stakeholders? Did we use market research to figure out if product Z we are about to create provides any meaningful value for the target audience? You may be surprised how often developers rush in to „save the day“ just to find out that X is on nuget, Y was never really needed and Z is already being rolled out by a competitor.

1 – Collaborate!

Communication is key and nothing beats face-to-face when it comes to implementing a software solution. But as soon as at least one member of your team is not sitting in the same room, things change. To be clear: if one member of your team is collaborating online, everyone has to. Apps like Slack or Microsoft Teams offer a great way to tie your workflow together but it is important that the entire team commits to a set of tools before the project begins.

2 – Scale your team

David Fowler recently tweeted

As a senior engineer, you have to decide if it’s better to do things
yourself or help junior developers grow

which brings me to the often shunned topic of knowledge management. Transferring personal knowledge to a colleague might be one of the hardest parts in your career but the reward is a team that truly scales. By the time you realize that you or a member of your team is a knowledge bottleneck you might already be knee-deep in a customer project, so plan accordingly.

3 – Code Outside-in, code SOLID

Ultimately, when starting to code, we should aim to produce clean and maintainable code. The outside-in approach focuses on satisfying the needs of stakeholders but I also like to apply it coding. It turns out that Visual Studio has pretty good support for sketching out the flow of your program without implementing the actual methods right away – a great way to do TDD, by the way. When you get down to the implementation it is prudent to adhere to design principles like SOLID or DRY and yet, realizing them is easier said than done. It’s easy to tell that methods with more than 100 lines of code probably have a complexity problem and that the same method shouldn’t appear five times across your code base. But, for example, getting inheritance or interfaces „right“ is usually a tad more difficult. I have found these basic tips pretty helpful:

  • keep your units of code small and focused
  • work your way from outside (i.e. user interface) down to the bottom layer
  • separate storage access code from your business logic and your business logic from the user interface
  • (integration- / unit-) test the hell out of everything you write

In the end, only writing code will help you improve writing even more code.

And reading a good book.

And getting involved with open source code.

4 – Git yourself a proper version control system

If you are still using centralized source control systems like SVN or TFVC, you might want to take a good look at git. Besides being used by major tech companies like Google, Microsoft or Netflix, it is easily the best way to implement a smooth feature branch workflow for your team, which is, in my opinion, a prerequisite for agile software development.

5 – Build, Test, Deploy – Automate all the things

If you’re reading this you’ve probably already written a console or web application, built it in your favorite IDE, tested it on your local machine and copied the binaries over to a file share or a web server. Enter DevOps, a set of practices that basically tells us to automate all the things we might have been doing by hand for too long. With the advent of cloud based applications and development tools it’s become extremely simple to spin up a complete DevOps environment in no time. But for smaller projects, even a simple script that builds a release version of your library and creates a nuget package is a first step towards automation. Eventually, this kind of automation reduces friction and increases confidence for you and your team.

macOS Sierra in Active Directory integrieren

pexels-photo-58420

In modernen Netzwerken finden sich heute große Anzahl verschiedenen Clientgeräte, darunter auch immer mehr macOS Clients. Die Anbindung an ein Windows Active Diretory erfordert ein paar Skripting Kenntnisse. Im folgenden Code Schnipsel zeigen wir, wie der Domain Join unter macOS Sierra durchzuführen ist.

# Terminal starten
# sudo sh joinDomain.sh
#
#!/bin/bash
domain=exampledomain.de
adUserName=exampleusername
adPass=examplepassword
computerName=examplename



systemsetup -setusingnetworktime on -setnetworktimeserver $domain

#Set ComputerName
scutil --set ComputerName $computerName
scutil --set LocalHostName $computerName
scutil --set HostName $computerName

#Join Domain
dsconfigad -add $domain -force -username "$adUserName" -password "$adPass"

#User Local Home Path
dsconfigad -mobile enable -mobileconfirm disable -localhome enable -useuncpath disable

#Add Domain Admins to Local Admins
dsconfigad -groups "Domain Admins,svc_DSM_RTS,u-ge-ws-admins" -alldomain enable

#Namespace Support
dsconfigad -namespace domain

#SSO
dsconfigad -enablesso

#Name and Password = TRUE | List Of Users = FALSE
sudo defaults write /Library/Preferences/com.apple.loginwindow SHOWFULLNAME -bool FALSE

Requesting a SAML token from ADFS in C#

NOTE: The code for my ADFS experiments is available at github

The problem

I set out to integrate a new .net web api project (and the client application consuming it) with ADFS authentication. Since I wanted to understand the nuts and bolts of ADFS tokens & using them with web apis, I chose not to use any “designer tools” in Visual Studio. Here’s what I’d like to achieve:

  • client application authenticates for the first time with username/password
  • use credentials to request security token from ADFS
  • convert the token to JWT format for usage in HTTP headers

Getting the token

Requesting the token is actually pretty easy once you use a little WCF magic (and know your ADFS endpoint). Here is the code for my TokenProvider. Please note that I use the excellent “Thinktecture.IdentityModel” nuget package.

public class ADFSUsernameMixedTokenProvider
{
    private readonly Uri ADFSUserNameMixedEndpoint;

    /// <summary>
    ///
    /// </summary>
    /// <param name="adfsUserNameMixedEndpoint">i.e. https://adfs.mycompany.com/adfs/services/trust/13/usernamemixed </param>
    public ADFSUsernameMixedTokenProvider(Uri adfsUserNameMixedEndpoint)
    {
        this.ADFSUserNameMixedEndpoint = adfsUserNameMixedEndpoint;
    }

    public GenericXmlSecurityToken RequestToken(string username, string password, string relyingPartyId)
    {
        var factory = new WSTrustChannelFactory(
                new UserNameWSTrustBinding(SecurityMode.TransportWithMessageCredential),
                 new EndpointAddress(this.ADFSUserNameMixedEndpoint));

        factory.TrustVersion = TrustVersion.WSTrust13;

        factory.Credentials.UserName.UserName = username;
        factory.Credentials.UserName.Password = password;

        var rst = new RequestSecurityToken
        {
            RequestType = RequestTypes.Issue,
            AppliesTo = new EndpointReference(relyingPartyId),
            KeyType = KeyTypes.Bearer
        };
        IWSTrustChannelContract channel = factory.CreateChannel();
        GenericXmlSecurityToken genericToken = channel.Issue(rst) as GenericXmlSecurityToken;

        return genericToken;
    }
}

Verhindern der Anmeldung an spezifische Office 365 Mandanten

Letzte Woche kam bei uns folgende Kundenanforderung herein:

Der Kunde erlaubt gewissen Benutzern keinerlei Zugang ins Internet, nun will er aber Office 365 einführen. Generell ist das ja kein Problem, da wir dann einfach nur die spezifischen Office 365 IP Adressen und URLs an den Firewalls bzw. Proxy-Servern freischalten lassen. Nun kam er Kunde aber zu uns zurück mit der Frage, was denn passiert, wenn sich der Benutzer privat einen eigenen Office 365 Mandanten erstellt, und über die dortigen Dienste wie Exchange Online oder OneDrive for Business Daten „durchtunnelt“.

Diese Fragestellung hatten wir bisher nicht, wir fanden Sie aber durchaus legitim und wir haben versucht eine Möglichkeit zu finden eine Whitelisting von spezifischen Tenants bzw. deren UPN Suffixe zu realisieren.

Obwohl Microsoft keine Möglichkeit für dieses Szenario bietet haben einen Ansatz erarbeitet. Dieser ist zwar nicht einfach umzusetzen, und „schön“ ist er schon gar nicht, aber im Testlabor hat es funktioniert:

Voraussetzung dafür ist, dass der HTTPS Verkehr des Clients IMMER durch eine intelligente Contentfiltering Lösung gejagt werden muss, die in der Lage ist den HTTPS Traffic aufzubrechen und hier konfigurierbare Rulesets anzuwenden

mslogin

Mann müsste auf diesem Proxy dann auf die URL „https://login.microsoftonline.com/common/userreal“ filtern, und jeglichen Traffic abbrechen, der in dieser URL nach dem Parameter „user=“ nicht eine der gewünschten Office 365 Tenants des Kunden enthält.

Hier ein Beispiel URL so einer Anmeldung:

https://login.microsoftonline.com/common/userrealm/?user=Andreas.Hoetzinger@gab-net.com&api-version=2.1&stsRequest=XXXXXXXXXXXXXXXXXXXXX&checkForMicrosoftAccount=false

Diese URL wird immer nach Verlassen des Login-ID Feldes auf https://login.microsoftonline.com aufgerufen, und dient dazu festzustellen ob die dieser Domänen Suffix überhaupt in O365 registriert ist, und wenn ja ob es sich um eine Federated-Domain oder um eine reine Azure AD Authentifzierung handelt.

Wir haben rausgefunden, dass wenn man diesen Aufruf bei unerwünschten Domains blockt, keine Anmeldung mit Accounts dieser Domäne möglich ist….

Wie gesagt das ganze ist natürlich nicht annähernd 100 % ausgetestet, wäre aber ein Ansatz.

lock

Microsoft muss Daten aus EU-Rechenzentrum nicht der US-Regierung übergeben

Ein großer Sieg für die US-Cloudindustrie und damit auch für uns!

Wie aktuell gemeldet wird, hat ein US-Berufungsgericht die Entscheidung eines untergeordneten Gerichts auf dem Jahre 2014 aufgehoben: Microsoft muss keine Daten aus seinem in Irland gehosteten Clouddienst herausgeben.

Endlich schwebt das Damoklesschwert dieses sogenannten „New-York Cases“ nicht mehr über uns! Es wurde höchstrichterlich klargestellt, dass sich ein US-Gericht nicht einfach über internationale Abkommen und Prozeduren hinwegsetzten kann.

Nun müssen wir diese berechtigte Diskussion nicht mehr mit unseren Kunden führen, und freuen uns auf weitere, viele neuen Office 365 und Azure Projekten in Deutschland!

Gericht