an intro for new employees
Identity is our business
1. Company culture TABLE2. iWelcome Product OF 2.1. Product description CONTENTS 2.2. UI-UX Principles3. Engineering principles 3.1.Technology strategy 3.2.The \"10 commandments\" 3.3. Key design decisions 3.4. 12 factor app 3.5. OWASP top 10 (2017)
4. Agile - SAFE - Scrum - Kanban4.1. Agile4.2. SAFE - Value - Principles - The 10 Essential Elements4.3. Scrum - The 5 Values - The 3 Ceremonies4.4 Kanban5. People TABLE 5.1. Objectives, values - The quote of Theo 5.2. Bene ts OF 5.3.Working practices CONTENTS6. Reference Cases
1. COMPANY CULTURE Lorem ipsum dolor sit amet, consectetuer adip- iscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lob- ortis nisl ut aliquip ex ea commodo consequat. Danny de Vreeze - CEO
Lorem ipsum dolor sit amet, consec-tetuer adipiscing elit, sed diam nonum-my nibh euismod tincidunt ut laoreetdolore magna aliquam erat volutpat.Ut wisi enim ad minim veniam, quis Danny de Vreeze - CEO
2.1. iWelcome PRODUCTEurope’s Identity Platform iWelcome provides Identity & Access Management as a service (IDAAS).With iWelcome’s cloud platform, organizations manage the identity lifecycle and access of their consumers,employees, business customers, partners and suppliers in a simple, secure and ef cient manner. 8
2.1. iWelcome PRODUCTIn the upcoming years, the developments will lead to consumers becoming more and more enabled to take controlover their personal data.Where each company has to deal with these challenges from a regulatory perspective, thesuccessful companies will embrace these changes as an enabeler to engage with customers in an even morevaluable manner. In order to do this, it is more vital than ever to understand what really drives customers.For more details, please see the Service description here: https://goo.gl/uhoRUU 9
2.2. UI-UX PRINCIPLESOur product(s) are being developed upon MaterialUI (MUI in short) framework, a merger of Google MaterialDesign and Facebook’s React Javascript engine. And build as a Mobile First tool.The mobile- rst approach is a tenet of progressive enhancement. It is the ideology that mobile design, as the hard-est, should be done rst. Once the mobile design questions are answered and put in design, upscaling to other deviceswill be easy.What it boils down to is that, the smallest of the designs will have only the essential features, so rightaway you have designed the heart of your UX. 10
2.2. UI-UX PRINCIPLESOur procedure follows these steps:1. Content Inventory — This is a spreadsheet or equivalent document containing all the elements you want to in-clude.2.Visual Hierarchy — Prioritize the elements in the content inventory and determine how to display the most im-portant elements prominently.3. Design with the smallest breakpoints and then scale up — Build the mobile wireframe rst, then use thatas the model for larger breakpoints. Expand the screen until there’s too much white space. 11
2.2. UI-UX PRINCIPLES5. Don’t count on hovers — It almost goes without saying, but designers often rely on hover and mouseover effectsin their interactive work. If you’re thinking mobile-friendly, don’t.There is no hover control for ngertips yet.6. Think “app” — Mobile users are accustomed to motion and a modicum of control in their experience. Thinkabout off-canvas navigation,https://www.uxpin.com/community/tutorials/navigation-drawers/ expendable widgets, AJAX calls, or other elements on the screen with which users caninteract without refreshing the page.7.Avoid large graphics — Landscape photos and complex graphics don’t display well when your screen is only afew inches across. Cater to mobile users with images that are readable on handheld screens. 12
2.2. UI-UX PRINCIPLES8.Test it in a real device — Nothing beats discovering for yourself how usable a website is (or isn’t). Step awayfrom your desktop/laptop computer and load up your product on a real phone or tablet.Tap through pages. Is the siteeasy to navigate? Does it load in a timely fashion? Are the text and graphics easy to read?The theming of the product for each client/tenant is being con gured in the MUI framework. 13
3. ENGINEERINGEngineering principles were de ned byOCTO = Of ce of the CTO that wasborn as one of the main pillar of iWel-come development. 14
3.1 TECHNOLOGY STRATEGY Lorem ipsum dolor sit amet, consectetuer adip- iscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lob- ortis nisl ut aliquip ex ea commodo consequat. Jordi Clement - CTO
Lorem ipsum dolor sit amet, consec-tetuer adipiscing elit, sed diam nonum-my nibh euismod tincidunt ut laoreetdolore magna aliquam erat volutpat.Ut wisi enim ad minim veniam, quis Jordi Clement - CTO
3.1 TECHNOLOGY STRATEGY1. Build a solid, secure, and scalable platform to easily deploy and manage our services for a large number ofenterprise customers, with millions of users who require great performance and 24/7 availability.2. Provide an ef cient pipeline to facilitate our development and delivery process and optimize our time-to-marketand ability to innovate (agility), but guarantee the quality of our product and service.3. Deliver a secure, feature rich set of productized CIAM capabilities that is easy to setup, can be con gured to thecustomer requirements and works in an open, web, mobile and API drivenecosystem. 17
3.1 TECHNOLOGY STRATEGY Key requirements Key requirements Key requirements platform pipeline developmentPerform and scale Rapid delivery of new Build a generic product functionalityto handle load of millions of users that can be tailored to the customers requirements so we stay agile and ahead of our competition through con gurationEasy to deploy and maintain Guarantee quality of the Build a secure productto handle our large customer base productin a single tenant model from a we store and process large amounts of sensiblesingle codebase into production: stability, performance and security personal informationFuture proof Perform push-button Build for Internet scale deploymentsdeploy and deliver today and tomorrows’s CIAM our customers have millions of users who demandservise in a quickly evolving technology landscape of any version of the product to any environment on excellent performanceusing our own and 3rd party developments demand 18
3.2 ENGINEERINGThe “10 commandments”Our service is used primarily by consumers. Excellent We deliver a generic service, that must belook and feel and great and simple user experience areessential. English is our default language, but everything con gurable per customer’s request. We have acan be translated through con guration.Support Unicode. Pay attention to UI and UX. Develop single codebase that is deployed to all ourand test for mobile rst and wide (current) browsersupport. customer tenants.Our code therefore is customer 1 agnostic, and con gurability is almost always a key requirement. Provide sensible defaults.Take care of upgrades and how to handle existing, new or obsolete con guration. 2 19
3.2 ENGINEERINGThe “10 commandments” We design, develop, test and run a security service. iWelcome stores large amounts of consumer data and credentials. Keeping that information safe is business critical for us. Keep in mind when storing, communicating, displaying or logging personal information and credentials. Use named accounts. Don’t ever store credentials in your code. Upgrade libraries and frameworks as often as possible. Encrypt, mask, anonymize or delete data where necessary.All API’s support authentication and autorisation, and provide and audit log of security related events. 3 20
3.2 ENGINEERINGThe “10 commandments” We design, develop, test and run a service for use by tens of millions of users.Our code must be able to handle that. Design, develop and test for concurrency and a large user database. Keep the memory and CPU footprint small. Assume everything to be able to handle 100s requests per second and scale out if needed.Applications should not keep state so we can deploy many.Think about concurrency and the non-happy ows you have to deal with to accomplish that. 4 21
3.2 ENGINEERINGThe “10 commandments”A deployed tenant works out of the box and does All our application- and platform code is fully documented. Demand time for propernot need con guration. Our applications contain documentation. It will be used to deploy, upgrade, run, con gure and maintain customer tenants. It willsensible defaults that can be overridden via the be used by colleague, partners and our customers. Implement all required testing that will be done inenvironment (Consul).The application should never the pipeline. Peer review this test code too.override this con guration, unless done through the 6 22admin API.When you spin up a tenant, locally or inthe VDC it just works without any con gurationnecessary. 5
3.2 ENGINEERINGThe “10 commandments”We test all functional, non-functional and security We keep changes small and iterate often to ensureaspects of our product. Demand time for properreview and testing. visibility in the development process.Peer-review for coding, functional, non-functional andsecurity issues. Implement unit, functional, UI, We keep our changes small and iteratively build ourregression tests. Happy and non-happy (chaosmonkey) tests. Static code analysis. Load, soak and software. We commit changes often (and at leaststress tests. Security tests. once a day) to push changes through the pipeline 7 and make those changes visible to everyone interested: for instance product management, OCTO, solution architects.We demo our progress at least every sprint. 8 23
3.2 ENGINEERINGThe “10 commandments” 9. We aim for continuous deployment. Our code must be accordingly designed and developed. Our end game is to push small code changes to production as often as possible. Possible multiple times a week or even a day.This requires a completely working, full set of tests but also a code base and applications that support automated upgrades/rollbacks, data model changes, provide backwards compatibility, versioning, dynamic reloads and feature toggling. Design and implement with these requirements in mind. 9 24
3.2 ENGINEERINGThe “10 commandments” 10. We develop Microservices,API- rst and keep a consistent, versioned API. We’ve designed Tulip with a Micro-services based architecture in mind.We started with bigger services and gradually getting smaller ones over time, as we learn, refactor and design accordingly. Our services expose a stable and fully documented API.This API does not break compatibility for any given major version of our code base.API “contracts“ are documented, tested and managed.The implementation of the API follows the API guideline document (TBD). 10 25
3.3 KEY DESIGN CHOICESSingle tenancy Continous deliveryInfrastructure-as-as-service MicroservicesAPI rst Security by design Privacy by default 26
3.4 ENGINEERING12 Factor App1. CodebaseA single codebase (but separate projects) tracked in revision control, used by everyone and everywhere. Platformand pipeline are code too!2. DependenciesExplicitly declare and isolate dependencies from the system. Don’t assume anything to be system wide available.3. Con gurationCon guration is anything that might differ between tenants and is stored in theenvironment, can be pulled externally or pushed to the tenant.We differentiatebetween infra an application con guration.4. Backing services (high)Databases, queues, mails servers etc. are treated a attached resources accessible via a simple endpoint. 27
3.4 ENGINEERING12 Factor App5. Build, release, run 28Strictly separate (and automate), build, release (deployment) and run (production) stages. Never implement stuff inrun directly!6. ProcessesExecute the app as a set of stateless processes. State is de ned in our databases, work ow systems etc., not in theindividual running apps.7. Port bindingOur apps make their services available over HTTP (or appropriate protocol) by binding to a port,f.i.: http://selfservice:80898. ConcurrencyWhen running a tenant, we should have a lot of little processes sharing the load.They all should work independently.This helps scale out when needed.
3.4 ENGINEERING12 Factor App9. DisposabilityMaximize robustness with fast startup and graceful shutdown. If it crashes, it should always be able to startupquickly.10. Dev/prod parityKeep development, staging, production environments as similar as possible and keep the gap between developmentand production small in terms of time, people and tools/technology.11. LogsOur apps should treat logs as event streams; they should not concern itself with routing or storing of its outputstream but write to an unbuffered stdout.12.Admin processesRun admin and management tasks as one-off processes from an identical environment as production. 29
3.5 ENGINEERINGOWASP coding standards - top 10 (2017)1. Injection - Injectionhttps://www.owasp.org/index.php/Top_10-2017_A1-Injection aws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent toan interpreter as part of a command or query.The attacker's hostile data can trick the interpreter into executingunintended commands or accessing data without proper authorization.2. Broken Authentication -https://www.owasp.org/index.php/Top_10-2017_A2-Broken_Authentication Application functions related to authentication and session management are oftenimplemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit otherimplementation aws to assume other users' identities temporarily or permanently.3. Sensitive Data Exposurehttps://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure - Many web applications and APIs do not properly protect sensitive data, such asnancial, healthcare, and PII.Attackers may steal or modify such weakly protected data to conduct credit card fraud,identity theft, or other crimes. 30
3.5 ENGINEERINGOWASP coding standards - top 10 (2017)Sensitive Data Exposure - Many web applications and APIs do not properly protect sensitive data, such as nancial,healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identitytheft, or other crimes.4ht.tpXs://wMww.oLwaspE.orxg/intdeex.prhpn/Toap_l10E-201n7_tA4i-XtMiLe_Exstern(alX_EntXities_E(XX)E) - Many older or poorly con gured XML processors evaluate external entityreferences within XML documents. External entities can be used to disclose internal les using the le URI handler,internal le shares, internal port scanning, remote code execution, and denial of service attacks.5. Broken Access Control -https://www.owasp.org/index.php/Top_10-2017_A5-Broken_Access_Control Restrictions on what authenticated users are allowed to do are often not properlyenforced. Attackers can exploit these aws to access unauthorized functionality and/or data, such as access otherusers' accounts, view sensitive les, modify other users' data, change access rights, etc. 31
3.5 ENGINEERINGOWASP coding standards - top 10 (2017)6. Security Miscon gurationhttps://www.owasp.org/index.php/Top_10-2017_A6-Security_Miscon guration - Security miscon guration is the most commonly seen issue. This is commonly aresult of insecure default con gurations, incomplete or ad hoc con gurations, open cloud storage, miscon guredHTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems,frameworks, libraries, and applications be securely con gured, but they must be patched/upgraded in a timely fashion.7. Cross-Site Scripting (XSS) - XSShttps://www.owasp.org/index.php/Top_10-2017_A7-Cross-Site_Scripting_(XSS) aws occur whenever an application includes untrusted data in a new webpage without proper validation or escaping, or updates an existing web page with user-supplied data using a browserAPI that can create HTML or JavaScript. XSS allows attackers to execute scripts in the victim's browser which canhijack user sessions, deface web sites, or redirect the user to malicious sites. 32
3.5 ENGINEERINGOWASP coding standards - top 10 (2017)8htt.psI:/n/wswew.ocwuaspr.oerg/iDndeex.pshep/rToipa_1l0i-2z01a7_tAi8o-Innsecu-reI_nDesseericaliuzartioen deserialization often leads to remote code execution.Even if deserialization aws do not result in remote code execution, they can be used to perform attacks, includingreplay attacks, injection attacks, and privilege escalation attacks.9.htUtpss:/i/nwgwwC.owoamsp.oprgo/inndeenx.pthsp/wToipt_h10-K20n17o_Aw9-nUsVingu_lCnomeproanbenitlsi_twieiths_-KCnoowmn_pVuolnneeranbtilsit,iessuch as libraries, frameworks, and othersoftware modules, run with the same privileges as the application. If a vulnerable component is exploited, such anattack can facilitate serious data loss or server takeover.Applications and APIs using components with knownvulnerabilities may undermine application defenses and enable various attacks andimpacts. 33
3.5 ENGINEERINGOWASP coding standards - top 10 (2017)10. Insuf cient Logging&Monitoringhttps://www.owasp.org/index.php/Top_10-2017_A10-Insuf cient_Logging%26Monitoring - Insuf cient logging and monitoring, coupled with missing or ineffectiveintegration with incident response, allows attackers to further attack systems, maintain persistence, pivot to moresystems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days,typically detected by external parties rather than internal processes or monitoring. https://www.owasp.org/index.php/Top_10-2017_Top_10 34
4.AGILE - SAFe - SCRUM - KANBAN4.1. AGILE Agile is the ability to create and respond to change in order to succeed in an uncertain and turbulent environment. Agile Software Development is an umbrella term for a set of methods and practices based on the valueshttps://www.agilealliance.org/agile101/the-agile-manifesto/ and principles expressed in the Agile Manifesto.https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/ Solutions evolve through collaboration between self-organizing, cross-functional teams utilizing the appropriate prac- tices for their context.
4.2 SAFe\"The Scaled Agile Framework (SAFe®) helps businesses address the signi cant challenges of developing and deliveringenterprise-class software and systems in the shortest sustainable lead time.\"(http://www.scaledagileframework.com/what-is-safe/)The 4 Core Values:1.Alignment: to keep pace with fast change, disruptive competitive forces, and geographically distributed teams;2. Built-in quality3.Transparency4. Program execution. 37
4.2 SAFe 38SAFe - Principles are based on nine immutable, underlying Lean and Agile Principles.These tenets and economicconcepts inspire and inform the roles and practices of SAFe.1.Take an economic view2.Apply systems thinking3.Assume variability; preserve options4. Build incrementally with fast, integrated learning cycles5. Base milestones on objective evaluation of working systems6.Visualize and limit WIP, reduce batch sizes, and manage queue lengths7.Apply cadence, synchronize with cross-domain planning8. Unlock the intrinsic motivation of knowledge worker9. Decentralize decision-making
4.2 SAFeThe 10 Essential Elements1. Lean-Agile PrinciplesSAFe practices are grounded in fundamental principles.That’s why you can be con dent that they apply well in yourcase. And if the practices don’t directly apply, the underlying principles can guide you to make sure that they aremoving on a continuous path to the ‘shortest sustainable lead time, with best quality and value to people and society. 39
4.2 SAFeThe 10 Essential Elements2. Real Agile Teams and TrainsReal Agile Teams and Agile Release Trains (ARTs) are fully cross-functional. They have everything, and everyone,necessary to produce a working, tested increment of the solution.They are self-organizing and self-managing, whichenables value to ow more quickly, with a minimum of overhead. Product Management, System Arch/Eng, andRelease Train Engineer provide content and technical authority, and an effective development process. ProductOwners and Scrum Masters help the Dev teams meet their PI Objectives. The Agile teams should engage thecustomer throughout the development process. 40
4.2 SAFeThe 10 Essential Elements3. Cadence and SynchronizationCadence provides a rhythmic pattern, a steady heartbeat for the development process. It makes routine those thingswhich can be routine. Synchronization allows multiple perspectives to be understood and resolved at the same time.For example, synchronization is used to pull the various assets of a system together to assess solution-level viability. 41
4.2 SAFeThe 10 Essential Elements4. PI PlanningNo event is more powerful in SAFe than PI Increment (PI) planning. It’s the cornerstone of the PI, which provides therhythm for the ART.When 100 or so people work together toward a common mission,Vision, and purpose, it’samazing how much alignment and energy it creates. Gaining that alignment in just two days can save months of delays. 42
4.2 SAFeThe 10 Essential Elements5. DevOps and ReleasabilityDevOps provides the culture, automation, Lean- ow, measurement, and recovery capabilities to enable an enterpriseto bridge the gap between development and operations. Releasability focuses on the enterprise’s ability to delivervalue to its Customers more often and according to the demand of the market.Together they allow an organizationto achieve better economic results by having more frequent releases and faster validation of hypotheses. 43
4.2 SAFeThe 10 Essential Elements6. System DemoThe primary measure of the ART’s progress is the objective evidence provided by a working solution in the SystemDemo. Every two weeks, the full system— the integrated work of all teams on the train for that iteration—is demoedto the train’s stakeholders. Stakeholders provide the feedback the train needs to stay on course and take correctiveaction. 44
4.2 SAFeThe 10 Essential Elements7. Inspect and AdaptInspect and Adapt is a signi cant event held every PI. A regular time to re ect, collect data and solve problems, theinspect and adapt assembles teams and stakeholders to assess the solution, and de ne and take action on the improve-ments needed to increase the velocity, quality, and reliability of the next PI. 45
4.2 SAFeThe 10 Essential Elements8. IP IterationThe Innovation and Planning Iteration occurs every PI and serves multiple purposes. It acts as an estimating buffer formeeting PI objectives, and provides dedicated time for innovation, continuing education, and PI planning and Inspectand Adapt events. It’s like extra fuel in the tank: Without it, the train may start straining under the ‘tyranny of theurgent’ iteration. 46
4.2 SAFeThe 10 Essential Elements9.Architectural RunwayArchitectural Runway consists of the existing code, components and technical infrastructure necessary to support theimplementation of high priority, near-term features, without excessive delay and redesign.Without enough investmentin the architectural runway, the train will slow down, needing to redesign for each new Feature. 47
4.2 SAFeThe 10 Essential Elements10. Lean-Agile LeadershipFor SAFe to be effective, the enterprise’s leaders and managers must take responsibility for Lean-Agile adoption andsuccess.They must become leaders who are trained—and become trainers in—these leaner ways of thinking andoperating.Without leadership taking responsibility for the implementation, the transformation will likely fail to achievethe full bene ts. 48
4.3 SCRUMThe 5 Values1. Focus-because we focus on only a few things at a time, we work well together and produce excellent work. We delivervaluable items sooner.2. Courage-because we work as a team, we feel supported and have more resources at our disposal.This gives us the courage toundertake greater challenges.3. Openness-as we work together, we express how we're doing, what's in our way, and our concerns so they can be addressed. 49
4.3 SCRUMThe 5 Values4. Commitment-because we have great control over our own destiny, we are more committed to success.5. Respect-as we work together, sharing successes and failures, we come to respect each other and to help each otherbecome worthy of respect. 50
Search
