Salle de torture "Cœur de Windows Azure Pack" (suite)

Il faut battre le fer quand il est chaud et torturer quand la chair est encore tendre. Dans la précédente salle de torture, nous avons traité uniquement les modules privé de Windows Azure Pack. Il nous reste encore les modules publics isolés sur notre second serveur Windows Azure Pack. Un petit rappel s’impose.

clip_image001

Va vous reviens? Bien, voyons ce qui nous attend coté certificats :

clip_image002

C’est déjà bien moins fourni. La séance de torture sera donc plus courte puisque seulement trois Web Services sont au programme :

  • AuthSite
  • TenantPublicAPI
  • TenantSite

Ce ne sont pas des inconnus pour nous. Coté zone DNS, ils dépendront de la zone DNS publique "Windowsazurepack.fr". Pour les mêmes raisons que dans le billet précédent, il nous faut aussi remplacer les ports de publication par défaut par des ports normalisés (TCP 443). Cela impliquera donc de répartir les Web Services sur différentes adresses IP. Le tableau ci-dessous référence les transformations que nous allons faire subir à nos Web Services.

Web Service

Ancienne URL

Adresse IP

Nouvelle URL

AuthSite https://localhost:30071 192.168.5.106 https://TenantAuthSite.windowsazurepack.fr:443
TenantPublicAPI https://localhost:30006 192.168.5.107 https://tenantpublicapi.windowsazurepack.fr:443
TenantSite https://localhost:300081 192.168.5.105 https://tenantportal.windowsazurepack.Fr:443

 

Il reste quand même pas mal de travail. Cette séance se découpera en deux parties :

  • La partie émergée de l’iceberg avec le portail des locataires et le site web d’authentification
  • La partie submergée de l’iceberg avec la partie publique de l’API des locataires

 

La partie émergée de l’Iceberg

Pour les modules publics, il faut tenir compte de l’expérience utilisateur de nos futurs locataires. La première chose qu’ils verront, c’est leur portail. On va donc personnaliser URL et le port pour qu’ils puissent utiliser ‘https://tenantportal.windowsazurepack.fr‘. Pour les détails plus complet, voir le billet Personnalisation des URL de Windows Azure Pack. Jusqu’ici on est en terrain connu, ça fait que chatouiller. Normal, on fait que commencer.

clip_image003

 

Note : Pour être pris en compte, il est nécessaire de redémarrer le site web.

Comme pour le portail d’administration, il y a un web service chargé d’authentifier les utilisateurs se connectant au portail des locataires. Dans IIS, c’est le site web "MgmtSvc-AuthSite" qui utilise ASP.NET Membership comme fournisseur d’authentification. Pour faire simple, derrière, le fournisseur d’authentification sera la base de données SQL Server de Windows Azure Pack.

Vu que c’était trop simple, j’ai décidé de corser un peu les choses et introduit quelques changements. Premier point, j’utilise un FQDN distinct de celui du portail des locataires. Ça permet d’introduire plus tard une séparation entre le portail des locataires et le Web Service en charge de l’authentification. C’est bon pour la montée en charge. Pour l’instant, les deux sont sur le même hôte mais qui sait, si le succès est au rendez-vous, il faudra bien être prêt à tenir la charge. Pour améliorer l’expérience utilisateur, j’ai retenu de binder le Web Service sur le port 443, comme le portail. Pour éviter les conflits au niveau IIS (et de devoir utiliser Server Name Indication (SNI)), j’ai donc introduit une nouvelle adresse IP sur mon serveur Windows Azure Pack Public.

clip_image004

Certes SNI a ses avantages mais aussi ses inconvénients :

J’ai toujours votre attention? Bien. On va commencer par quelques sujets simples : Reconfigurer l’URL du portail des locataires de Windows Azure Pack. L’objectif est de présenter "https://tenantportal.windowsazurepack.fr" à nos futurs locataires et de se préparer à la haute disponibilité.

Get-MgmtsvcFqdn -Namespace "TenantSite" -Server "SQL01.WindowsAzurepack.Lan"

Set-MgmtSvcFqdn -NameSpace "TenantSite" -FullyQualifiedDomainName "Tenantportal.Windowsazurepack.Fr" -port 443 -Server "SQL01.Windowsazurepack.lan"

clip_image005

Après le portail, le site d’authentification associé. C’est le même principe mais avec le FQDN ‘https://tenantAuthSite.WindowsAzurepack.fr‘. C’est vers lui que les demandes d’authentification vont être redirigées sur le port 443. C’est plus user-friendly.

Get-MgmtSvcFqdn -Namespace "AuthSite" -Server "SQL01.WindowsAzurePack.lan"

Set-MgmtSvcFqdn -Namespace "AuthSite" -FullyQualifiedDomainName "Tenantauthsite.windowsazurepack.fr" -port 443 -Server "SQL01.WindowsAzurePack.lan"

clip_image006

Les FQDN posés, on peut maintenant référencer le ‘https://tenantAuthSite.WindowsAzurepack.fr‘ comme URL pour le fournisseur d’identité. C’est une information que nous devrons référencer dans la base de données. On va donc créer une variable pour stocker le ‘connectionstring’ de notre base SQL ainsi qu’une autre variable qui référence le FQDN du partenaire de confiance vers lequel la demande d’authentification va être redirigée.

$Connectionstring = "Data Source=SQL01.Windowsazurepack.lan;User ID=SA;Password=*************"

$federationmetadata = "https://tenantauthsite.Windowsazurepack.fr/federationmetadata/2007-06/federationmetadata.xml"

Get-MgmtSvcRelyingPartySettings -Target "Tenant" -Server "SQL01.WindowsAzurepack.lan" | Format-List

Set-MgmtSvcRelyingPartySettings -Target "Tenant" -MetadataEndpoint $federationmetadata -ConnectionString $Connectionstring

clip_image007

Comme pour le portail d’administration, si on est redirigé pour authentification, il faudra bien revenir au portail et présenter le claims à consommer. Pour cela on doit l’indiquer à notre fournisseur d’authentification. Dans l’état actuel de notre plateforme c’est le ASP.NET Membership. Faut juste savoir à quelle URL on va rediriger.

$Federationmetadata = "https://tenantportal.windowsazurepack.fr/Federationmetadata/2007-06/federationmetadata.Xml"

Get-MgmtSvcIdentityProviderSettings -Target "Membership" -Server "SQL01.Windowsazurepack.lan"

Set-MgmtSvcIdentityProviderSettings -Target "Membership" -MetadataEndpoint $Federationmetadata -ConnectionString $Connectionstring

clip_image008

A ce stade, le portail doit être accessible. Certes, il n’y a pas encore de locataire mais on peut déjà tester la fonction "Sign-up" pour être un early-adopter:)

clip_image009

Dans la configuration actuelle de Windows Azure Pack, rien n’interdit à un utilisateur de créer son propre compte (on avait déjà vu que c’était possible). Par contre, notre installation n’inclus aucun "ressource provider" et encore moins de "plan" auquel l’utilisateur peut s’abonner. Le portail est bien opérationnel mais y a rien à consommer. Aller circulez, y a plus rien à voir en surface.

clip_image010

 

La partie submergée de l’iceberg

Comme vu dans le billet Windows Azure Pack–Les APIs publiques des locataires, le portail, ce n’est que la surface d’un service cloud digne de ce nom. En dessous, on a des API que nos locataires peuvent accéder pour exploiter les ressources mises à disposition. La première chose que nos futurs locataires vont voir, c’est le la partie publique du TenantAPI disponible sur le serveur public de Windows Azure Pack. Encore un certificat auto-signé à remplacer dans IIS.

clip_image011

 

Note : Redémarrer le site web est encore essentiel. On va écraser le binding actuel, le TenantPublicAPI ne répondra plus.

Maintenant, on commence à le savoir, changer l’information dans IIS, c’est bien mais si on ne la change pas aussi dans la base de données de Windows Azure Pack, on va pas aller bien loin. Donc acte.

Get-MgmtSvcFqdn -Namespace ‘TenantPublicAPI’ -ConnectionString $ConnectionString | Format-Table -AutoSize

Set-MgmtSvcFqdn -Namespace ‘TenantPublicAPI’ -ConnectionString $ConnectionString -FQDN "tenantpublicapi.windowsazurepack.fr" -Port 443

clip_image012

Tout comme pour le module TenantAPI, il faut corriger le paramètre DisableSSLCertvalidation. Comme l’indique le mode Verbose de la commande Get-MgmtsvcSetting, l’opération consiste à ajouter un paramètre dans le fichier Web.Config du site web.

Get-MgmtSvcSetting -namespace "TenantPublicAPI" | Format-Table

Set-MgmtSvcSetting -namespace "TenantPublicAPI" -Name "DisableSslCertValidation" -Value False -Verbose

clip_image013

 

Si tout se passe bien, l’API publique des locataires est accessible via l’url ‘https://tenantpublicapi.windowsazurepack.fr‘. Le dire c’est bien mais le prouver c’est mieux. On avait déjà abordé le sujet dans le billet "Windows Azure Pack–Les APIs publiques des locataires".

Cependant, on doit interrompre la séance de torture. Dans cette installation, nous n’avons pas encore abordé le sujet des "Resources providers". Or sans eux, pas de ressources à proposer dans un “plan” auquel le locataire pourrait souscrire. Pour valider que cela fonctionne bien, il faudra mettre en œuvre un premier Resource Provider". Ça tombe bien, ce sera le sujet de notre prochaine séance de torture.

 

Vous pensiez sérieusement en avoir fini? Mais c’était que l’échauffement.

 

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Benoit

Simple, yes, Secure Maybe, by design for sure, Business compliant always!

Les derniers articles par Benoit (tout voir)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.