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 aservice (IDAAS).With iWelcome’s cloud platform, organizations manage the identitylifecycle and access of their consumers, employees, business customers, partners andsuppliers in a simple, secure and ef cient manner.
2.1. iWelcome PRODUCTIn the upcoming years, the developments will lead to consumers becoming more andmore enabled to take control over their personal data.Where each company has todeal with these challenges from a regulatory perspective, the successful companies willembrace 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 whatreally drives customers.For more details, please see the Service description here: https://goo.gl/uhoRUU
2.2. UI-UX PRINCIPLESOur product(s) are being developed upon MaterialUI (MUI in short) framework, amerger of Google Material Design and Facebook’s React Javascript engine. And buildas a Mobile First tool.The mobile- rst approach is a tenet of progressive enhancement. It is the ideologythat mobile design, as the hardest, should be done rst. Once the mobile designquestions are answered and put in design, upscaling to other devices will be easy.Whatit boils down to is that, the smallest of the designs will have only the essential features,so right away you have designed the heart of your UX.
2.2. UI-UX PRINCIPLESOur procedure follows these steps:1. Content Inventory — This is a spreadsheet or equivalent document containing allthe elements you want to include.2.Visual Hierarchy — Prioritize the elements in the content inventory and determinehow to display the most important elements prominently.3. Design with the smallest breakpoints and then scale up — Build the mobilewireframe rst, then use that as the model for larger breakpoints. Expand the screenuntil there’s too much white space.
2.2. UI-UX PRINCIPLES5. Don’t count on hovers — It almost goes without saying, but designers often rely onhover and mouseover effects in 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 controlin their experience.Think about off-canvas navigation,https://www.uxpin.com/community/tutorials/navigation-drawers/ expendable widgets,AJAX calls, orother elements on the screen with which users can interact without refreshing the page.7.Avoid large graphics — Landscape photos and complex graphics don’t display wellwhen your screen is only a few inches across. Cater to mobile users with images that arereadable on handheld screens.
2.2. UI-UX PRINCIPLES8.Test it in a real device — Nothing beats discovering for yourself how usable awebsite is (or isn’t). Step away from your desktop/laptop computer and load up yourproduct on a real phone or tablet.Tap through pages. Is the site easy to navigate? Doesit 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 theMUI framework.
3. ENGINEERINGEngineering principles were de nedby OCTO = Of ce of the CTO thatwas born as one of the main pillar ofiWelcome development.
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 servicesfor a large number of enterprise customers, with millions of users who require greatperformance and 24/7 availability.2. Provide an ef cient pipeline to facilitate our development and delivery process andoptimize our time-to-market and ability to innovate (agility), but guarantee the qualityof our product and service.3. Deliver a secure, feature rich set of productized CIAM capabilities that is easy tosetup, can be con gured to the customer requirements and works in an open, web,mobile and API driven ecosystem.
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
3.2 ENGINEERINGThe “10 commandments”1. Our service is used primarily by consumers. Excellent look and feel and great andsimple user experience are essential. English is our default language, but everything canbe translated through con guration. Support Unicode. Pay attention to UI and UX.Develop and test for mobile rst and wide (current) browser support.2. We deliver a generic service, that must be con gurable per customer’s request.We have a single codebase that is deployed to all our customer tenants. Our codetherefor is customer agnostic, and con gurability is almost always a key requirement.Provide sensible defaults.Take care of upgrades and how to handle existing, new orobsolete con guration.
3.2 ENGINEERINGThe “10 commandments”3. We design, develop, test and run a security service. iWelcome stores large amountsof consumer data and credentials. Keeping that information safe is business critical forus. Keep in mind when storing, communicating, displaying or logging personal informationand credentials. Use named accounts. Don’t ever store credentials in your code. Upgradelibraries and frameworks as often as possible. Encrypt, mask, anonymize or delete datawhere necessary.All API’s support authentication and autorisation, and provide and auditlog of security related events.
3.2 ENGINEERINGThe “10 commandments”4. We design, develop, test and run a service for use by tens of millions of users.Ourcode must be able to handle that. Design, develop and test for concurrency and a largeuser database. Keep the memory and CPU footprint small.Assume everything to be ableto handle 100s requests per second and scale out if needed. Applications should notkeep state so we can deploy many.Think about concurrency and the non-happy owsyou have to deal with to accomplish that.
3.2 ENGINEERINGThe “10 commandments”5. A deployed tenant works out of the box and does not need con guration.Our applications contain sensible defaults that can be overridden via the environment(Consul).The application should never override this con guration, unless done throughthe admin API.When you spin up a tenant, locally or in the VDC it just works withoutany con guration necessary.6. All our application- and platform code is fully documented. Demand time for properdocumentation. It will be used to deploy, upgrade, run, con gure and maintain customertenants. It will be used by colleague, partners and our customers. Implement all requiredtesting that will be done in the pipeline. Peer review this test code too.
3.2 ENGINEERINGThe “10 commandments”7. We test all functional, non-functional and security aspects of our product. Demandtime for proper review and testing. Peer-review for coding, functional, non-functional andsecurity issues. Implement unit, functional, UI, regression tests. Happy and non-happy(chaos monkey) tests. Static code analysis. Load, soak and stress tests. Security tests.8. We keep changes small and iterate often to ensure visibility in the developmentprocess.We keep our changes small and iteratively build our software. We commitchanges often (and at least once a day) to push changes through the pipeline and makethose changes visible to everyone interested: for instance product management, OCTO,solution architects.We demo our progress at least every sprint.
3.2 ENGINEERINGThe “10 commandments”9. We aim for continuous deployment. Our code must be accordingly designed anddeveloped. Our end game is to push small code changes to production as often aspossible. Possible multiple times a week or even a day.This requires a completelyworking, full set of tests but also a code base and applications that support automatedupgrades/rollbacks, data model changes, provide backwards compatibility, versioning,dynamic reloads and feature toggling. Design and implement with these requirements inmind.
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 withbigger services and gradually getting smaller ones over time, as we learn, refactor anddesign accordingly. Our services expose a stable and fully documented API.This API doesnot break compatibility for any given major version of our code base.API “contracts“ aredocumented, tested and managed.The implementation of the API follows the APIguideline document (TBD).
3.3 KEY DESIGN CHOICESSingle tenancy Continous deliveryInfrastructure-as-as-service MicroservicesAPI rst Security by design Privacy by default
3.4 ENGINEERING -12 FACTOR APP1. CodebaseA single codebase (but separate projects) tracked in revision control, used byeveryone and everywhere. Platform and pipeline are code too!2. DependenciesExplicitly declare and isolate dependencies from the system. Don’t assume anything tobe 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 asimple endpoint.
3.4 ENGINEERING -12 FACTOR APP5. Build, release, runStrictly separate (and automate), build, release (deployment) and run (production)stages. Never implement stuff in run directly!6. ProcessesExecute the app as a set of stateless processes. State is de ned in our databases,work ow systems etc., not in the individual running apps.7. Port bindingOur apps make their services available over HTTP (or appropriate protocol) bybinding to a port, f.i.: http://selfservice:80898. ConcurrencyWhen running a tenant, we should have a lot of little processes sharing the load.Theyall should work independently.This helps scale out when needed.
3.4 ENGINEERING -12 FACTOR APP9. DisposabilityMaximize robustness with fast startup and graceful shutdown. If it crashes, it shouldalways be able to startup quickly.10. Dev/prod parityKeep development, staging, production environments as similar as possible and keepthe gap between development and production small in terms of time, people andtools/technology.11. LogsOur apps should treat logs as event streams; they should not concern itself with rout-ing or storing of its output stream but write to an unbuffered stdout.12.Admin processesRun admin and management tasks as one-off processes from an identical environmentas production.
3.5 ENGINEERINGOWASP coding standards - top 10 (2017)1. Injection - Injection aws, such as SQL, NoSQL, OS, and LDAP injection, occur whenhttps://www.owasp.org/index.php/Top_10-2017_A1-Injectionuntrusted data is sent to an interpreter as part of a command or query.The attacker'shostile data can trick the interpreter into executing unintended commands or accessingdata without proper authorization.2. Broken Authenticationhttps://www.owasp.org/index.php/Top_10-2017_A2-Broken_Authentication - Application functions related to authentication and ses-sion management are often implemented incorrectly, allowing attackers to compromisepasswords, keys, or session tokens, or to exploit other implementation aws to assumeother 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 pro-tect sensitive data, such as nancial, healthcare, and PII. Attackers may steal or modifysuch weakly protected data to conduct credit card fraud, identity theft, or other crimes.
3.5 ENGINEERINGOWASP coding standards - top 10 (2017)Sensitive Data Exposure - Many web applications and APIs do not properly protectsensitive data, such as nancial, healthcare, and PII. Attackers may steal or modify suchweakly protected data to conduct credit card fraud, identity theft, or other crimes.4. XML External Entities (XXE) - Many older or poorly conhttps://www.owasp.org/index.php/Top_10-2017_A4-XML_External_Entities_(XXE) gured XML processorsevaluate external entity references within XML documents. External entities can be usedto disclose internal les using the le URI handler, internal le shares, internal portscanning, remote code execution, and denial of service attacks.5. Broken Access Controlhttps://www.owasp.org/index.php/Top_10-2017_A5-Broken_Access_Control - Restrictions on what authenticated users are allowed todo are often not properly enforced.Attackers can exploit these aws to accessunauthorized functionality and/or data, such as access other users' accounts, viewsensitive les, modify other users' data, change access rights, etc.
3.5 ENGINEERINGOWASP coding standards - top 10 (2017)6. Security Miscon guration - Security misconhttps://www.owasp.org/index.php/Top_10-2017_A6-Security_Miscon guration guration is the most commonly seenissue.This is commonly a result of insecure default con gurations, incomplete or ad hoccon gurations, open cloud storage, miscon gured HTTPheaders, and verbose errormessages containing sensitive information. Not only must all operating systems,frameworks, libraries, and applications be securely con gured, but they must bepatched/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 web page without proper validation or escaping, or updatesan existing web page with user-supplied data using a browser API that can create HTMLor 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.
3.5 ENGINEERINGOWASP coding standards - top 10 (2017)8. Insecure Deserialization - Insecure deserialization often leadshttps://www.owasp.org/index.php/Top_10-2017_A8-Insecure_Deserialization to remote code execution. Even if deserialization aws do not result in remote code execution, theycan be used to perform attacks, including replay attacks, injection attacks, and privilegeescalation attacks.9h.ttUps://swiwnw.gowaCsp.oorgm/indepx.pohpn/Toepn_10t-2s017w_Ai9t-UhsingK_Conmopownennts_wVithu_Klnnowen_rVaulnberaibliilittieises-Components, such as libraries,frameworks, and other software modules, run with the same privileges as theapplication. If a vulnerable component is exploited, such an attack can facilitate seriousdata loss or server takeover.Applications and APIs using components with knownvulnerabilities may undermine application defenses and enable various attacks andimpacts.
3.5 ENGINEERINGOWASP coding standards - top 10 (2017)10. Insuf cient Logging&Monitoring -https://www.owasp.org/index.php/Top_10-2017_A10-Insuf cient_Logging%26Monitoring Insuf cient logging and monitoring, coupledwith missing or ineffective integration with incident response, allows attackers to furtherattack systems, maintain persistence, pivot to more systems, and tamper, extract, ordestroy data. Most breach studies show time to detect a breach is over 200 days, typicallydetected by external parties rather than internal processes or monitoring. https://www.owasp.org/index.php/Top_10-2017_Top_10
3.5 ENGINEERINGOWASP coding standards - top 10 (2017)10. Insuf cient Logging&Monitoringhttps://www.owasp.org/index.php/Top_10-2017_A10-Insu cient_Logging%26Monitoring - Insuf cient logging and monitoring, coupled withmissing or ineffective integration with incident response, allows attackers to furtherattack systems, maintain persistence, pivot to more systems, and tamper, extract, ordestroy data. Most breach studies show time to detect a breach is over 200 days, typicallydetected by external parties rather than internal processes or monitoring. https://www.owasp.org/index.php/Top_10-2017_Top_10
4.AGILE - SAFe - SCRUM - KANBAN4.1. AGILEAgile is the ability to create and respond to change in order to succeed in an uncertainand turbulent environment.Agile Software Development is an umbrella term for a set of methods and practicesbased on the values and principleshttps://www.agilealliance.org/agile101/the-agile-manifesto/ expressed in the Agile Manifesto.Solutions evolve through collaboration between self-organizing, cross-functional teamsutilizing the appropriate practices for their context.
4.2 SAFe\"The Scaled Agile Framework (SAFe®) helps businesses address the signi cant challeng-es of developing and delivering enterprise-class software and systems in the shortestsustainable lead time.\"(http://www.scaledagileframework.com/what-is-safe/)The 4 Core Values:1.Alignment: to keep pace with fast change, disruptive competitive forces, andgeographically distributed teams;2. Built-in quality3.Transparency4. Program execution.
4.2 SAFeSAFe - Principles are based on nine immutable, underlying Lean and Agile Principles.These tenets and economic concepts 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 workers9. 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 dentthat they apply well in your case.And if the practices don’t directly apply, the underlyingprinciples can guide you to make sure that they are moving on a continuous path to the‘shortest sustainable lead time, with best quality and value to people and society.
4.2 SAFeThe 10 Essential Elements2. Real Agile Teams and TrainsReal Agile Teams and Agile Release Trains (ARTs) are fully cross-functional. They haveeverything, and everyone, necessary to produce a working, tested increment of thesolution.They are self-organizing and self-managing, which enables value to ow morequickly, with a minimum of overhead. Product Management, System Arch/Eng, andRelease Train Engineer provide content and technical authority, and an effectivedevelopment process. Product Owners and Scrum Masters help the Dev teams meettheir PI Objectives.The Agile teams should engage the customer throughout thedevelopment process.
4.2 SAFeThe 10 Essential Elements3. Cadence and SynchronizationCadence provides a rhythmic pattern, a steady heartbeat for the development process.It makes routine those things which can be routine. Synchronization allows multipleperspectives to be understood and resolved at the same time.For example, synchronization is used to pull the various assets of a system together toassess solution-level viability.
4.2 SAFeThe 10 Essential Elements4. PI PlanningNo event is more powerful in SAFe than PI Increment (PI) planning. It’s the cornerstoneof the PI, which provides the rhythm for the ART.When 100 or so people work togethertoward a common mission,Vision, and purpose, it’s amazing how much alignment andenergy it creates. Gaining that alignment in just two days can save months of delays.
4.2 SAFeThe 10 Essential Elements5 DevOps and ReleasabilityDevOps provides the culture, automation, Lean- ow, measurement, and recovery capa-bilities to enable an enterprise to bridge the gap between development and operations.Releasability focuses on the enterprise’s ability to deliver value to its Customers moreoften and according to the demand of the market.Together they allow an organizationto achieve better economic results by having more frequent releases and faster valida-tion of hypotheses.
4.2 SAFeThe 10 Essential Elements6. System DemoThe primary measure of the ART’s progress is the objective evidence provided by aworking solution in the System Demo. Every two weeks, the full system— the integratedwork of all teams on the train for that iteration—is demoed to the train’s stakeholders.Stakeholders provide the feedback the train needs to stay on course and take correctiveaction.
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, collectdata and solve problems, the inspect and adapt assembles teams and stakeholders toassess the solution, and de ne and take action on the improvements needed to increasethe velocity, quality, and reliability of the next PI.
4.2 SAFeThe 10 Essential Elements8. IP IterationThe Innovation and Planning Iteration occurs every PI and serves multiple purposes. Itacts as an estimating buffer for meeting PI objectives, and provides dedicated time for in-novation, continuing education, and PI planning and Inspect and Adapt events. It’s likeextra fuel in the tank:Without it, the train may start straining under the ‘tyranny of theurgent’ iteration.
4.2 SAFeThe 10 Essential Elements9.Architectural RunwayArchitectural Runway consists of the existing code, components and technical infra-structure necessary to support the implementation of high priority, near-term features,without excessive delay and redesign.Without enough investment in the architecturalrunway, the train will slow down, needing to redesign for each new Feature.
4.2 SAFeThe 10 Essential Elements10. Lean-Agile LeadershipFor SAFe to be effective, the enterprise’s leaders and managers must take responsibilityfor Lean-Agile adoption and success.They must become leaders who are trained—andbecome trainers in—these leaner ways of thinking and operating. Without leadershiptaking responsibility for the implementation, the transformation will likely fail to achievethe full bene ts.
4.3 SCRUMThe 5 Values1. Focus-because we focus on only a few things at a time, we work well together and produceexcellent work.We deliver valuable 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 to undertake greater challenges.3. Openness-as we work together, we express how we're doing, what's in our way, and our concernsso they can be addressed.
4.3 SCRUMThe 5 Values4. Commitment -because we havegreat control over our own destiny, we are more com-mitted to success. 5. Respect -as we work together, sharing suc-cesses and failures, we come to respect each other andto help each other become worthy of respect.
Search
