SharePoint Conference 2014, Las Vegas: Kolmas päivä


SharePoint Conference 2014, Las Vegas: Kolmas päivä



[Uusin päivitys tähän artikkeliin tehty 6. maaliskuuta klo 2.20 Suomen aikaa]

Muut SharePoint Conference 2014-tapahtumaan liittyvät artikkelit:

Tässä artikkelissa nostan esiin SharePoint Conference 2014-konferenssin aikana kuuntelemiani luentoja ja niistä mieleen jääneitä havaintoja ja vinkkejä.
Luennot jotka löydät tästä artikkelista:
  • Developing socially connected apps with Yammer, SharePoint and OpenGraph (SPC371, Chris Johnson)
  • Authentication and authorization infrastructure in Microsoft SharePoint 2013 (SPC401, Paolo Pialorsi)
  • Advanced development patterns for SharePoint (SPC302)
  • Real-world examples of FTC to CAM transformations (SPC325, Steve Walker, Vesa Juvonen)

Developing socially connected apps with Yammer, SharePoint and OpenGraph (SPC371, Chris Johnson)

Aamun ensimmäinen luento eilisillan bileiden jälkeen – kyllä tämä tästä! Paikallinen Starbucks-henkinen pikimusta (ja ehkä pari tuntia seisotettu) kahvi auttaa kyllä pysymään virkeänä.

Screenshot 2014-03-05 18.51.06.png

(Kaikki kuvakaappaukset SPC371-esityksen kalvoista)

Tällä luennolla otetaan tuntumaa Yammerin API-rajapintoihin ja OpenGraphiin. Lisäksi luvassa on demorikas luento, saa nähdä käykö kuten eilen – tunnin demo, valmiista projektista, josta jää lopulta hyvin vähän kotiinviemistä.

Screenshot 2014-03-05 19.03.28.png

2014-03-05 09.07.30.jpg

Yammer tarjoaa rajapinnat, jolla Yammer voidaan integroida tiiviisti osaksi omia sovelluksia – tai vaikkapa SharePointia. Rajapintoja on useita:

  • REST-rajapinta, perinteisiä REST-kutsuja varten. Tämä lienee yksinkertaisin ja kätevin, kun Yammerista tarvitaan tietoa muihin sovelluksiin. Tämä palauttaa oletuksena JSON-muotoista dataa.
  • JavaScript-kirjasto, jolla Yammeria voidaan paremmin käskyttää asynkronisesti.
  • OpenGraph, joka on kutsurajapinta jolla käyttäjän aktiviteetit voidaan palauttaa Yammerille (lisätietoa)
  • Embed Widget, jolla Yammer voidaan upottaa osaksi sivua. Tämähän on saatavilla ainakin SharePointiin ja SharePoint Onlineen omana SharePoint-hosted appina.
  • SDK:t saatavilla lisäksi Ruby on Railsille, Pythonille, iOS-alustalle ja Windows Phonelle.
Screenshot 2014-03-05 19.13.27.png
REST-rajapinnan käyttö on – kuten yleensä – yksinkertaista. HTTP GET/POST/DELETE:llä voidaan hakea ja palauttaa tietoa Yammeriin. Kaikki kutsut menevät HTTPS:n yli suojattuna. Yksinkertaisimmillaan voidaan kutsua oman Yammer-verkon tietoja HTTP GETillä osoitteesta https://www.yammer.com/api/v1/messages.json. Kutsu palauttaa JSON-pakettina viestit. Koska JSON näyttää usein selaimessa sekamelskalta, voit purkaa paketin esim. JSON Viewerillä. Tein esityksen aikana testin, tältä näyttää SPC 2014 Yammer-verkoston viestit JSON-paketin kautta katsottuna:
Screenshot 2014-03-05 19.21.59.png
Ja tässä JSON Viewerillä avattuna:
Screenshot 2014-03-05 19.18.10.png
REST-rajapinnalla saadaan käsiteltyä Yammerista tietoa seuraavista lähteistä:
  • Viestit (Messages)
  • Ryhmät (Groups)
  • Käyttäjät (Users)
  • Hälytykset (Notifications)
  • Ehdotukset (Suggestions)
  • Autocomplete-tiedot
  • Kutsut (Invitations)
  • Haku (Search)
  • Verkot (Networks)

Luennolla käytettiin Postman-työkalua, joka on myös erittäin hyvä lisätyökalu REST-kutsujen debuggaukseen. Tämä toimii ainakin Chrome-selaimessa plugininä.

Kaikki REST-rajapinnan URLit on listattu kätevästi tässä:

Screenshot 2014-03-05 19.24.51.png

Autentikoinnin osalta teknologiana on aina OAuth 2. Käyttäjät autentikoituvat normaalisti, mutta omat appsit pitää autentikoida hakemalla app authnetication token osoitteesta https://www.yammer.com/client_applications. Rekisteröinnissä saatu token on voimassa ikuisesti, eli normaalia autentikointi-token-polkkaa, minkä OAuth yleensä vaatii, ei tarvita. Seuraavat tiedot tulee täyttää, kun app esitellään Yammeriin:

Screenshot 2014-03-05 19.28.13.png

Appsin lisäyksen jälkeen sivulla listaan app tietoineen:

Screenshot 2014-03-05 19.29.15.png

Serveripuolen autentikointi hoidetaan ohjaamalla käyttäjä Yammerin OAuth-osoitteeseen (https://www.yammer.com/dialog/oauth?client_id=CLIENTID&redirect_uri=OMA_URI). Yammer palauttaa kutsun jälkeen HTTP-querystringissä koodin, jota käyttämällä tehdään vielä yksi kutsu Yammer.comiin koodin + client-secret-arvon kanssa. Tämä tapa on käyttökelpoinen, kun tehdään omaa palvelinpään logiikkaa jonka täytyy ohjelmallisesti kommunikoida Yammerin kanssa.

Screenshot 2014-03-05 19.30.30.png

Client-side-ratkaisuna logiikka on yksinkertaisempi: Kutsutaan Yammer.comia client_id ja redirect_uri -parametreilla, ja paluuarvona Yammer palauttaa access tokenin. Kutsu tehdään osoitteeseen https://www.yammer.com/dialog/oauth?client_id=CLIENTID&redirect_uri=OMA_URI&response_type=token.

Yammer JavaScript SDK hoitaa kaiken tämän autentikointilogiikan omalla wrapperillaan, ja osaa renderoida myös Log in with Yammer-napin omaan sovellukseen. Tämä on yksinkertaisin tapa upottaa Yammer-logiikkaa omaan web-palveluun, koska pelkän yam.js -skriptin lisääminen tuottaa kaiken tarvittavan logiikan.

Screenshot 2014-03-05 19.35.51.png

Yammer JavaScript SDK:n käyttöohjeita laajemmin kuvattuna löytyy täältä.

OpenGraph on aktiviteetteihin pohjautuva rajapinta, jonka kautta voidaan toteuttaa erilaisia activityjä (Create, Delete, Update, Follow, Like). Kutsumalli on “Henkilö + Aktiviteetti + Lähde + Viesti”. Endpoint REST-kutsuille on https://www.yammer.com/api/v1/activity.json. HTTP-kutsun content-typenä täytyy olla application/json, sekä lisäksi Authorization-token Bearer-etuliitteellä (esim. “Authorization: Bearer abcdefg”). OpenGraphin logiikka on kohtuullisesti kuvattu täällä.

OpenGraph on kätevä sovelluksille, joiden aktiviteeteista on hyödyllistä nostaa dataa Yammer-feediin. Esimerkkinä luennolla annettiin aktiviteetti, jossa kehittäjä kuittaa lähdekoodia sisään repositoryyn, ja repository kuittaa  Yammeriin projektiryhmälle muutoksesta.

Screenshot 2014-03-05 19.54.05.png

Visiona on, että Yammeria voitaisiin käyttää sosiaalisen median storena/syöttöpaikkana, johon kaikki keskitetään. Sinänsä sama ajatus kuin aikoinaan SharePoint 2013:sta Newsfeed-toiminnallisuudessa mutta nyt myös laajemmin tiedon aggregointia muualta – nimenomaan OpenGraphin avulla. Jatkossa varmasti myös Office Graph pelaa tässä isoa roolia.

Authentication and authorization infrastructure in Microsoft SharePoint 2013 (SPC401, Paolo Pialorsi)

Screenshot 2014-03-05 20.26.26.png

Paolo Pialorsin setti seuraavaksi. Luettuani pari Paolon kirjaa osasin odottaa, että nyt mennään syvälle ja kovaa. Autentikointi ja autorisointi ovat tärkeitä konsepteja SharePointissa, niin on-premises-ympäristöissä kuin osana Office 365-alustaa ja Windows Azurea.

Screenshot 2014-03-05 20.46.46.png

SharePoint 2013:sta autentikointitarina on lähes identtinen kuin SharePoint 2010:ssä. Vanhanaikainen (“deprecated”, eli hylätty mutta vielä mukana 2013:sta) Classic-autentikointimalli on yhä mukana. Varsinaisesti kuitenkin kaikki autentikointipyynnöt tehdään Claims-autentikoinnilla. Itse autentikointi voidaan tehdä Windows-autentikoinnilla (NT User eli Basic NTLM tai Kerberos-autentikointi), lomakepohjaisesti (FBA, Forms-Based Authentication jolloin voidaan tunnistautua esim. LDAPia tai SQL-kantaa vasten) tai SAML 1.1:llä (esim. ADFS:llä tapahtuvat federoidut tunnistautumiset ja Azure Access Control Services).

Screenshot 2014-03-05 20.49.36.png

Paolo kävi läpi Claims-mallin, ja yksittäisen claimin rakenteen. Claimien rakenne on myös kuvattu täällä: http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=25255. 

Windows Azure ACS 2.0 on Identity Provider (IdP) ja Security Token Services (STS), ja osa Azure-pilvipalvelua. Käyttö on ilmaista, mutta käyttöönottoon tarvitaan Azure-tilaus. ACS 2.0 tukee yleisimpiä tunnistautumisprotokollia: OAuth 2.0, WS-Trust, WS-Federation. Lisäksi tokeneina tuetaan SAML 1.1 ja 2.0:aa sekä JSON Web Tokeneita (JWT).

Screenshot 2014-03-05 21.03.51.png

2014-03-05 11.04.59.jpg

ACS:n provisiointi tehdään Azuren hallintaliittymästä (https://manage.windowsazure.com). Oletuksena on Windows Live ID-identity provider, jota ei voi poistaa. Sen voi piilottaa käyttäjiltä, tai jättää sellaisenaan käyttöön. Kun lisätään uusi identity provider (esim. Facebook tai LinkedIn), täytyy ACS:lle kertoa Idp:n metatiedot.

2014-03-05 11.05.42.jpg

Metatietoja täytettäessä voidaan määritellä mitä oikeuksia Idp:ltä pyydetään. Demossa tehtiin Facebook-Idp, ja pyydetään sähköpostikenttään oikeudet. Lisäksi ACS-profiiliin täytyy määritellä Relying Party, eli se taho joka Idp:tä tulee käyttämään – tässä tapauksessa paikallinen SharePoint 2013. URL on muotoa http(s)://oma.osoite.fi/_trust/default.aspx.

Token-formaatiksi Idp-asetuksissa pitää määritellä SAML 1.1, koska se on oletuksena ainoa, jota SharePoint tukee claimeissa. Tämän tokenin voi salata haluttaessa.

Claim ruleilla voidaan määritellä mitä saapuville (incoming) claimeille tehdään ja miten ne välitetään (outgoing) eteenpäin.

ACS antaa lopuksi FederationMetadata.xml:n, josta voidaan poimia X.509-sertifikaatti talteen. Tämä täytyy lisätä SharePointin luotetuksi sertifikaatiksi, jotta ACS:ltä tulevat claimit otetaan vastaan (federoidaan). Tämä tehdään PowerShellillä.

2014-03-05 11.15.14.jpg

Kun Idp on lisätty, on SharePointissa optiona web application-kohtaisesti mahdollisuus lisätä ulkoinen tunnistautumiskeino ACS:n kautta.

Custom Claims Providerilla voidaan laajentaa claimien käsittelyä ohjelmallisesti. Custom Claims Provider (CCP) mahdollistaa claimin laajentamisen (augmentation) ja selvittämisen (resolve, esimerkiksi People Pickerissä). CCP on saatavilla vain on-premises-alustaan, ei Office 365:een koska käytännössä ratkaisu täytyy tehdä farmitason sovelluksena.

Screenshot 2014-03-05 21.21.31.png

Oman CCP:n toteuttaminen tehdään esimerkiksi C#:lla, periyttämällä SPClaimProvider-luokasta oma luokka.

App authentication toimii SharePoint-appseille, mutta vain CSOMin tai REST APIn kautta, ja niin, että kutsujana on app – ei käyttäjä.

Autentikointitapoja appseille on kolme:

  • Internal App Authentication, jossa app kutsuu CSOM/REST APIa, ja välittää parametrina käyttäjän SAML-tokenin. SharePoint-hosted appsit käyttävät tätä.
  • External app authentication via OAuth, jossa app kutsuu CSOM/REST APIa ja välittää Azure ACS:n tokenin mukana. Access tokenissa voi olla mukana app ja user-identiteetit. Tämä on ainoa tuettu autentikointimalli appseille Office 365:ssa.
  • External app authentication via Server to Server, jossa app kutsuu CSOM/REST APIa mukanaan access token, joka on allekirjoitettu X.509-sertifikaatilla johon SharePoint luottaa. Tämä vaatii luottosuhteen SharePointin ja appsin välillä – esimerkiksi Provider-hosted appsina.
Tässä on hyvä diagrammi SharePoint-appsien autentikoinnin kulusta:

Screenshot 2014-03-05 21.30.37.png

Server-to-server, eli High-trust appsit ovat käytännössä Provider-hosted appseja, jotka pohjautuvat X.509-sertifikaattien luottosuhteisiin. Näin appi voi olla esimerkiksi ASP.NET-sovellus SharePointin ulkopuolella, ja se saadaan näkymään käyttäjälle normaalina lisätoiminnallisuutena osana SharePointia.

Appseille myönnetään oikeudet (authorization) kaikki-tai-ei-mitään -mallilla. Käyttäjä kuittaa hyväksynsä appsin pyytämät oikeudet, mutta kuitenkin omien käyttöoikeuksiensa rajoissa. Oikeuksia ei voida myöhemmin muuttaa, vain poistaa kokonaan.

Appsilla on aina full control omaan app webiinsä. Muita oikeuksia ei oletuksena ole. Oikeustasoja on useita, mm. Site Collection, Web Site, List, Tenant, Services. Oikeusattribuutit ovat Read-Only, Write, Manage, Full Control.

Lopuksi yhteenveto claimsien, OAuthin ja S2S:n roadmapista – ei mitään tajunnanräjäyttävää, koska taulukossa listattu SharePoint Video Portal julkistettiin jo aiemmin tällä viikolla.

Screenshot 2014-03-05 21.51.21.png

Advanced development patterns for SharePoint

Lounaan jälkeen advacend development patterns asiaa. Näyttää olevan nimenomaan server-to-server, eli tässä yhteydessä provider-hosted appsien kanssa pelaamista.

Tässä yhteydessä SharePoint Conferencen käyttämä MySPC-sivustokin näytti saaneen tarpeekseen:

Screenshot 2014-03-05 23.58.45.png

No, mennään ilman taustatietoja tällä kertaa.

Esityksessä käytiin läpi helpdesk-sovellus, ja käytettiin sitä mallina erilaisiin skenarioihin miten appseja kannattaa rakentaa.

UI:n ja brändäyksen osalta ei ole käytetty SharePointin Chrome Control-kontrollia, vaan brändätty suoraan omaan käyttöliittymään tarvittavat linkit, “Back to”-toiminto ja navigaatio.

Paljon ei jäänyt käteen tästä, kun pääosa 75 minuutin esityksestä kuluu sovelluksen eri osioiden esittelyyn ja pienten lähdekoodi-snippettien hämmästelyyn.

Real-world examples of FTC to CAM transformations (SPC325, Steve Walker, Vesa Juvonen)

Noniin, sitten taas perinteisten räätälöintien äärelle hetkeksi. Vesa “Vesku” Juvonne ja Steve Walker täräyttävät käytännön esimerkkejä – ja näitä ei muuten tällä viikolla ole mitenkään äärettömän montaa näkynyt.

2014-03-05 15.15.35.jpg

Esityksen alussa nyt jo useaan otteeseen nähty Office 365 platformin esittely nykyaikaisin lasein katsottuna:

2014-03-05 15.18.28.jpg

Esityksen referenssitoteutuksena käytetään UPM:lle toteutettua ratkaisua.

2014-03-05 15.22.25.jpg

Tavoitteena oli siirtyä nykyisistä full-trust code-ratkaisuista ympäristöön, joka on riittävän ketterä liiketoiminnan tarpeisiin, pilvipalvelu-ystävällinen ja kustannustehokas.

2014-03-05 15.25.26.jpg

Vanha SharePoint 2010-pohjainen ympäristö oli laaja, ja teknisesti haastava.

2014-03-05 15.30.24.jpg

Ajatuksena siirryttäessä CAM (Cloud App Model) malliin on tehdä asioita vaiheittain – eikä kerralla täysin valmis ja lopullista.

2014-03-05 15.35.21.jpg

Mallina isommissa räätälöinneissä on provider-hosted apps. UPM:n ympäristö on Office 365 Dedicated-alustalla, ja provider-hosted appseja ajetaan on-premisenä:

2014-03-05 15.37.42.jpg

Ulkoasullisesti työtiloissa räätälöintiä on vähän – custom master page taustalla, mutta pitkälti out of box-käyttöliittymällä:

2014-03-05 15.42.31.jpg

Intranetin puolella appseja ei käytetä käyttöliittymän osalta ollenkaan. Kaikki dynaamiset toiminnot ja räätälöinti pyritään ajamaan JavaScriptillä, ilman appsien vaatimaa IFramea.

2014-03-05 15.45.18.jpg

Tässä vaiheessa demottiin UPM:n tuotantoympäristössä olevaa tiimisaittia, ja tiimisaitin provisiointiin toteutettua appia.

Nykyiset SharePoint 2013-sivustot, joissa full-trust-koodia on yleensä runsaasti, täytyy migroida uuteen CAM-malliseen tulevaisuuteen. Olennaista on vaihtaa page layoutit ja master paget pois – jälleen kerran vaiheittain.

2014-03-05 16.06.28.jpg

Site columnit ja content typet ovat hankalampi pähkinä purtavaksi. Tähän on tulossa jollain aikavälillä Microsoftilta helpottava ratkaisu mutta toistaiseksi riippuvuus content-kannan ja tiedostojen välillä on olemassa, jos metatietorakenteita on provisioitu deklaratiivisesti.

2014-03-05 16.09.42.jpg

 



Microsoft-arkkitehti, erityisosaamisena SharePoint, Office 365 ja Microsoft Azure. Microsoft MVP & Microsoft Regional Director & Microsoft Certified Master (MCM). Sähköposti: jussi.roine@sulava.com, Twitter: @jussiroine