Micro Services and LaSalle Software

Microservices & Laravel: How I Do It With My LaSalle Software
York Region PHP May 02, 2018
<?php

{
!1

Bob Bloom, York Region PHP Meet-up, May 02, 2018
Micro Services and
Laravel:
How I (will) do it with
my LaSalle Software

Quick Intro
!3

I authored FOSS Laravel Framework based software that I called LaSalle
Software Version One.

The purpose was to oﬀer basic out-of-the-box features with which to base
client engagements, and for my own apps.

Included a blog, authentication with 2FA, and automatic 
CRUD forms based on a database.

Developed as a suite of packages to be installed into a single monolithic
app.

• https://github.com/lasallecms

!4

York Region PHP May 02, 2018!5

Originally, version two was to be a big clean up operation:

• Lots and lots of refactoring

• Use latest version of the Laravel Framework

• Add some new features
!6

Then I decided that I also had to “modernize” my software:

• Micro services

• DevOps galore

I had no idea what I was getting myself into!

This presentation is really about my going down The Micro
Services Rabbit Hole.
This presentation is not intended as a pedagogical exposition.
My new FOSS software is s-l-o-w-l-y taking shape

(https://github.com/lasallesoftware)

• This presentation is an overview of my journey down the
rabbit hole, as I figure out how to do a generic open
source Laravel Framework based microservices
architecture for version two of my LaSalle Software

• My focus is building a basic scaffolding with which to
build my own stuff, and as a starting point for client
engagements

• I have found the lexicon and terminology endless,
confusing, and mind numbing. Let’s see if I can do this
presentation in “plain English”
!8

Micro Services
!9

micro = small
!10

Service = doing something for someone else

!11
One day you’ll do me a service, but that day may never come…

Services = plural of service = lots of “service”
!12

Each microservice [has] its
own codebase, infrastructure,
and database.
!13
(https://www.nginx.com/resources/glossary/microservices/)

• A service is a completely independent thing.

• it’s own repo(s),  
it’s own git workﬂow,  
it’s own dev team (potentially),  
it’s own dev/staging/production servers (potentially),  
it’s own deployment,  
it’s own URL 
it’s own internal oﬃce politics!

• it’s own language! ==> not necessarily PHP :-(
!14

• personally, I regard a service as an app.

• Is this app an API? ==> probably 
Does this app use Docker? ==> maybe 
Has its own deployment? ==> of course

• The key idea: a service is a completely independent thing
!15

You Mean…

• There are many independent apps? => yes

• Each of these apps is separately developed? => yes

• Each of these apps is separately deployed? => yes

• Each of these apps is separately monitored? => yes

• Each of these apps is on its own cloud server?  
=> yes… well, maybe some, maybe all, maybe none
!16

Microservices is feasible because:

• Cloud economics

• CI/CD technology

• Do not forget the signiﬁcant contribution of FOSS!
!17

Microservices looks like a consultant’s nirvana
!18
• More apps!

• More APIs!

• More DevOps!

• More teams!

Lots and lots of juicy billing
opportunities! Won’t be long
when the consultant can buy
their yacht!

But do customers get enough
beneﬁts out of micro services
so that they can buy their own
yachts?

• Monolithic software is ok.

• Everything is built as a single unit:

‣ one app

‣ one production server

‣ one production deployment sequence

‣ one URL
!19

When you have an ever growing monolith app:

• Fear that adding something will break something

• Difficult to on-board new devs (and managers!)

• incrementing more server resources to run the beast

• Difficulty creating native apps

• Difficulty creating new web app front-end on a different
URL (eg Featured Product site)
!20

• At some point, it does not look so crazy — and consultant
self serving! — to break up a monolithic app into
completely separate API’s.
!21

(https://blog.smartbear.com/apis/why-you-cant-talk-about-
microservices-without-mentioning-netflix/)

• In 2008, Netflix started as a monolith. One wrong semi-
colon brought down the entirety of Netflix. Not conducive
to delivering 24/7/365 streams optimized for speed, along
with multiple front-end apps, subscription management,
etc.
!22

• Monolith hosted at data centre.

• Had to build data centres to keep up with growth

• Moved to AWS —> increase capacity in minutes

• Bonus with AWS —> scale different components at
different rates. Scale a customer service app at a different
rate than a static-ish product catalogue
!23

“The microservices architecture also allowed Netﬂix to
create about 30+ independent engineering teams that
could work on diﬀerent release schedules which helped
increase the agility and productivity of the development
process.”
!24

Actual called “Death Star”

https://www.slideshare.net/gjuljo/microservices-architectures-
become-a-unicorn-like-netﬂix-twitter-and-hailo
Nice slideshare to look at, esp #2:

Independent services talk to each other…

• This is where things get interesting

• How does a service know that the request coming in is
from a bona ﬁde member of the micro services “family”,
and not from somewhere that is made to look as if it is
from a legit micro service?

• User session in the front-end does not mean that a user is
“logged in” to the back-end services
!27

Communication happens:

• Front-end app to back-end service

• Back-end service to another back-end service(s)

• Back-end service to a front-end app

• Back-end service to a third party API
!28

(Front-end app talks to multiple “back-end” APIs, Back-end services talk to other back-end APIs
—> there’s a lot of chit-chat between independent microservices going on)

Microservices: The Gateway
• Single point of entry for all front-ends (clients) 
(http://microservices.io/patterns/apigateway.html)
!30

Microservices: The Gateway
• Here is another diagram: (https://www.nginx.com/blog/building-microservices-using-an-api-gateway/)

OAuth2
!32

• My microservices journey about security inexorably led to:

OAuth2
• “The OAuth 2.0 authorization framework enables a third-party application
to obtain limited access to an HTTP service, either on behalf of a
resource owner by orchestrating an approval interaction between the
resource owner and the HTTP service, or by allowing the third-party
application to obtain access on its own behalf.”

• (from the RFC —> https://tools.ietf.org/html/rfc6749)
!33

OAuth2:
• Industry standard protocol (specification) for an app to
access a user’s account on another API.

• Is a specification, not a technology

• Convenient that there’s a common way for users to give
your app permission to use a third party app

• The RFC reads like a legal document — personally I find it
quite irritating
!34

OAuth2:
• Section 1.8 of the RFC: “OAuth 2.0 provides a rich authorization
framework with well-defined security properties. However, as a
rich and highly extensible framework with many optional
components, on its own, this specification is likely to produce a
wide range of non-interoperable implementations. In addition, this
specification leaves a few required components partially or fully
undefined (e.g., client registration, authorization server capabilities,
endpoint discovery). Without these components, clients must be
manually and specifically configured against a specific
authorization server and resource server in order to interoperate.”
!35

OAuth2:
• I ﬁnd the terminology imprecise:  
“authorization”,  
“authentication”,  
“security”

• When talking about OAuth2, I recommend that you irritate your peers
by seeking precise deﬁnitions.

• I read article after article that glides over terminology, but what you
think of as “X” is not always what the article assumes is “X”

• My personal favourite frustration? What is “auth”?
!36

OAuth2 — more links:
• https://oauth.net/2/

• https://aaronparecki.com/oauth-2-simpliﬁed/

• https://www.owasp.org/index.php/Main_Page

• https://www.nginx.com/blog/introduction-to-microservices/

!37

• We are lucky to have a package created and maintained by the Laravel Project
that implements the OAuth2 speciﬁcation

• https://github.com/laravel/passport

• From Passport’s doc  
(https://laravel.com/docs/master/passport#introduction)

• “Laravel already makes it easy to perform authentication via traditional
login forms, but what about APIs? APIs typically use tokens to
authenticate users and do not maintain session state between requests.
Laravel makes API authentication a breeze using Laravel Passport, which
provides a full OAuth2 server implementation for your Laravel application
in a matter of minutes. Passport is built on top of the League OAuth2
server that is maintained by Alex Bilbie.”

!39

Excerpt from Passport’s composer.json:
"require": {
"php": ">=7.0",
"firebase/php-jwt": "~3.0|~4.0|~5.0",
"guzzlehttp/guzzle": "~6.0",
"illuminate/auth": "~5.6",
"illuminate/console": "~5.6",
"illuminate/container": "~5.6",
"illuminate/contracts": "~5.6",
"illuminate/database": "~5.6",
"illuminate/encryption": "~5.6",
"illuminate/http": "~5.6",
"illuminate/support": "~5.6",
"league/oauth2-server": "^6.0",
"phpseclib/phpseclib": "^2.0",
"symfony/psr-http-message-bridge": "~1.0",
"zendframework/zend-diactoros": "~1.0"
},
"require-dev": {
"mockery/mockery": "~1.0",
"phpunit/phpunit": "~6.0"
},
!40

Well, yes and no!
(https://github.com/thephpleague/oauth2-server)

(top half of page at https://oauth2.thephpleague.com/authorization-server/which-grant/)
critical!!

(bottom half of page at https://oauth2.thephpleague.com/authorization-server/which-grant/)

I am ﬁnding myself shying away from using Laravel’s Passport and
The League’s OAuth2 Server packages.

I am thirsting right now for a solution that is stripped of the things I
do not need, has what I do need, and is incredibly easy to follow.

I need to implement just a piece of OAuth2 because right now
because all LaSalle Software’s front-ends and back-ends are “in
the family”.

An important aspect of my Software’s communication between
apps and services will be JSON Web Tokens.
!44
& OAuth2

JSON Web Tokens
!45

JSON Web Tokens (JOTs)
• JSON Web Token (JWT) is a compact claims representation format intended for
space constrained environments such as HTTP Authorization headers and URI
query parameters. JWTs encode claims to be transmitted as a JSON [RFC7159]
object that is used as the payload of a JSON Web Signature (JWS) [JWS] structure
or as the plaintext of a JSON Web Encryption (JWE) [JWE] structure, enabling the
claims to be digitally signed or integrity protected with a Message Authentication
Code (MAC) and/or encrypted. JWTs are always represented using the JWS
Compact Serialization or the JWE Compact Serialization. The suggested
pronunciation of JWT is the same as the English word "jot".

• (https://tools.ietf.org/html/rfc7519)

!46

JSON Web Tokens (JOTs)
• Comprised of three sections, each section demarcated with a period (“.”)

• header.payload.signature

• Header is a JSON object: 
{ 
"typ": "JWT", 
"alg": "HS256" 
}

• Payload is the data (“claims” in the JOT vernacular): 
{ 
"userId": “123" 
}

• Signature is computed, using the payload, using a secret string, and using encryption speciﬁed in the header.

• The JOT: 
 
$encoded_header = base64urlEncode($header)  
$encoded_payload = base64urlEncode( $payload) 
 
$secret = “satchmo”; 
$hashed_signature = Hash ( $encoded_header_payload, $secret ); 
 
$JOT = $encoded_header + “.” + $encoded_payload + “.” + $hashed_signature;
!47

JSON Web Tokens (JOTs) 
• Base64 encoding RFC: https://tools.ietf.org/html/rfc4648

• Online base64urlencoder: http://www.simplycalc.com/base64url-encode.php

• From the ﬁrst comment at http://us.php.net/manual/en/function.base64-encode.php: 
 
 
function base64_url_encode($input) 
{ 
return strtr(base64_encode($input), '+/=', ‘-_,'); 
} 
 
 
function base64_url_decode($input) 
{ 
return base64_decode(strtr($input, '-_,', '+/=')); 
}

!48

JSON Web Tokens (JOTs) — Links: 
• https://jwt.io/

• I recommend the JWT Handbook:  
https://auth0.com/resources/ebooks/jwt-handbook  
(registration or tweet required)

• Online base64urlencoder: http://www.simplycalc.com/base64url-encode.php

• The JWT PHP package The League’s OAuth2 Server package uses: https://github.com/lcobucci/jwt

• JSON Web Signature RFC: https://tools.ietf.org/html/rfc7515

• JSON Web Encryption RFC: https://tools.ietf.org/html/rfc7516

• JSON Web Key RFC: https://tools.ietf.org/html/rfc7517

• JSON Web Algorithms RFC: https://tools.ietf.org/html/rfc7518

• https://stormpath.com/blog/jwt-the-right-way

JSON Web Tokens (JOTs): 
encoding does not equal encryption 
• Encoding can be decoded easily

• The purpose of encoding is to make the JOT small in size

• The signature is encrypted, but the signature is also optional —> should always
have a signature!

• Encrypt the payload

• The League’s OAuth2 Server package uses https://github.com/defuse/php-
encryption

Go “Headless”
• “A JWT consists of a protected payload together with a plaintext "header" section. This
can contain various bits of information such as the algorithms used to sign or encrypt the
payload or application-specific information to be used by intermediaries on the network,
e.g. for message routing. In a lot of cases, this information is redundant and it is
downright dangerous to trust its contents anyway. If you do not need to interoperate
with third parties that expect standard JWTs, you can save some space and eliminate a
whole class of vulnerabilities by simply stripping off the header section when
producing a JWT and then recreate it from known data before parsing. I call these
"headless JWTs" and recommend you use them wherever you can. 
 
Stripping the header is easy: just remove everything up to the first "." character in the
encoded JWT. To reconstruct the JWT, just base64url-encode a fixed header identifying
the known algorithm and parameters and prepend it to the headless JWT.”

• (from https://dev.to/neilmadden/7-best-practices-for-json-web-tokens)

Secret Key Management
• It’s important to change your secret key.

• AWS has a key management service: https://aws.amazon.com/kms

• “AWS Key Management Service (KMS) is a managed service that
makes it easy for you to create and control the encryption keys
used to encrypt your data, and uses FIPS 140-2 validated hardware
security modules to protect the security of your keys. AWS Key
Management Service is integrated with most other AWS services to
help you protect the data you store with these services.”

• LaSalleSoftware.ca

• @bobbloom

• github.com/lasallesoftware

• bob.bloom@lasallesoftware.ca
!53
This presentation was created using Keynote.

Microservices & Laravel: How I Do It With My LaSalle Software (My Journey)

Copyright 2018 South LaSalle

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

}
!54

Micro Services and LaSalle Software

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Micro Services and LaSalle Software

Semelhante a Micro Services and LaSalle Software (20)

Último

Último (20)

Micro Services and LaSalle Software