[{"content":"Hello world, welcome to my notebook.\nLast year I started thinking that It could be interesting to share some of my notes with the world. But because I am not a good writer and did not feel like creating a blog, so you get the next best thing, a bunch of random notes.\nProbably not useful for most people but maybe someone can find something interesting one day.\n","permalink":"https://notes.robinvanhove.me/posts/hello/","summary":"\u003cp\u003eHello world, welcome to my notebook.\u003c/p\u003e\n\u003cp\u003eLast year I started thinking that It could be interesting to share \u003cem\u003esome\u003c/em\u003e of my\nnotes with the world. But because I am not a good writer and did not feel like\ncreating a blog, so you get the next best thing, a bunch of random notes.\u003c/p\u003e\n\u003cp\u003eProbably not useful for most people but maybe someone can find something\ninteresting one day.\u003c/p\u003e","title":"Hello world!"},{"content":"This post contains the notes that I took during FOSDEM 2026. The big new topics this year seemed to be on AI \u0026amp; digital sovereignty. But off course the main subject matter of the conference will always be beer open source.\nThe following notes are some ramblings combining what the speakers said and thoughts I had while listening. I took them for future references and decide to publish them because 🤷 why not.\nNotes on day 2.\nStands It\u0026rsquo;s always fun to see the myriad of OSS projects having a stand at FOSDEM. After coming here a few years I had seen most of them already so I did not spend too much time browsing around. I did make sure that a picked up some stickers off course!\nI did learned about privacyidprivacyIDEA \u0026ldquo;a modular authentication server\u0026rdquo;. Honestly I am not exactly certain what it is, it\u0026rsquo;s not an Idp like keycloak but focusses only on MFA. It seems like way to centrally mange (hardware) tokens \u0026amp; keys for organisations.\nThe radio amateurs had an interesting stand as always and I was reminded that hamcon will take place later this year.\nMain track on desktops Picture actually taken on day 2.\nWayland compositors for fun and profit Turns out that building a wayland compositor can be fun and apparently easy because of existing rust libraries. Wayland can even work on the small screen of the Turris opeon source router.\nKDE at 30: Still looking ahead 🤔 I have always loved the KDE destkop, but I keep switching between KDE \u0026amp; GNOME (at the time of writing I\u0026rsquo;m on GNOME). Maybe I should consider switching again, and maybe trye NixOS as a desktop distro.\nI learned some new things such as that KDE started in Germany and KHTML started as a KDE project and became webkit over time, which is now used a lot by Apple.\nKDE hardware: Slimbooks, Steamdeck.\nEnd of 10 campaign: not all old Windows 10 devices need to be thrown away.\nPlsame mobile 6: Difficult to install on mobile because of protected hardware. Some new device called Mecha?\nPlasma bigscreen is still a thing.\nLinux on the Desktop – Why Digital Sovereignty Starts Here For organisations that we work with/for it\u0026rsquo;s important to achieve digital sovereignty. To avoid price gauging, to have freedom of choice and decentralization.\nLinux Client Management: Foreman, Config management (SaltStack, Ansible, \u0026hellip;), GitOps.\nOpenDesk: Zendis (German government digital sovereignty agency) office suite. Existing FOSS tools such as Univention for Identity management and Nordeck for video conferencing.\nAn EU OS?\nSecuring enterprise linux: antivirus \u0026amp; disabeling USB device access.\n🤔 IS ClamAV actually usefull on a linux desktop? Becasue AFAIK it mostly searches for fingerprints of windows viruses.\nChallenging to integrate with proprietary software. No fully sovereign solution at the moment.\nImmutable OS is nice to have: Secure, easy to manage.\nSovereign IDM, Himmelblau from samba: seamless Azure Entra ID and Intune integration for Linux.\nSecurity Devroom All your keybaords are belong to us Van Eck phreaking: signal leakage, live demonstraion on the BBC youtube: BBC tempest, skip the shakespeare part demo of stealing contents of PC monitor.\nTempest: A signal problem\nBooks: Spy Catcher \u0026amp; The SPY in Moscow station.\nType writer noise can be used to determine text, soundproofiing help the attacker: improving signal to noise ratio.\nSkype-Type: Keyboard acoustisc eavesdropping tool during call. Nowdays difficult due too noise filters.\nMarkus G. Kuhm: Large paper on emissions\nRecording of the rest of the talk on DEFFCON.\nThe invisible key: Securing the new attack vector of OAuth tokens Hackers don\u0026rsquo;t break in, they login.\n\u0026ndash; Corey Nachreiner (probably)\nYou can\u0026rsquo;t apply conditional access to tokens. 🤔 Is that not what the Shared signals framework tries to solve?\nFive major conserns:\nLongevity of token and forgotten access Scope / privilege creep Supply chain risk: the domino effect Token leakage Revocation gaps and off boarding failure, Off boarding a user does not mean off boarding a token. Common attack vectors such as during the attack on salesforce. By Gangs: Scattered spider, ShinyHunters. Attacks still often involve social engineering.\nHow to avoid: Audit OAuth Apps, Centralize logs, use canary tokens\nStop granting overprivileged permissions to applications.\nConditional access requires support on the browser? (🤔 not sure what the speaker meant with this).\nUse mTLs for certificate bound client credentials flow or DPoP.\nIPSIE, which is the OpenID working group tackeling shared signals.\nDynamic Bot Blocking with Web-Server Access-Log Analytics You don\u0026rsquo;t have to use cloudflare for bot detection.\nTempest-tech.com\nDDOS prectection \u0026amp; Web security\nFingerprinting of user agents: JA3/JA4, p0f, tempest.\nLog shipping to clickhouse.\n","permalink":"https://notes.robinvanhove.me/posts/2026/fosdem-1/","summary":"\u003cp\u003eThis post contains the notes that I took during FOSDEM 2026. The big new topics\nthis year seemed to be on AI \u0026amp; digital sovereignty. But off course the\nmain subject matter of the conference will always be \u003cdel\u003ebeer\u003c/del\u003e open source.\u003c/p\u003e\n\u003cp\u003eThe following notes are some ramblings combining what the speakers said and\nthoughts I had while listening. I took them for future references and decide to\npublish them because 🤷 why not.\u003c/p\u003e","title":"FOSDEM 2026 Day 1"},{"content":"Notes on day 1\nIdentity and Access Management Devroom This room is cursed.\n\u0026ndash; The video volunteer when entering the room in the morning.\nDay two stared of great with a some great presentations in the IAM devroom. I woke up early so I could get a seat on the front row and was happy that I did.\nThomas Darimont giving a presentation on OpenID\u0026rsquo;s shared signals framework.\nAn Introduction to the OpenID Shared Signals Framework SSF tries to normalize the signals to do Continuous Access Evaluation\nUse Cases:\nReal-time Session Revocation Compromsed Account Alert Automated User Deprovisioning Building blocks: Security Event, Transmitter (System emitting event), Receiver, Stream and subscription on events. Security Event tokens are an IETF RFC\nProfiles: Set of use cases and events\nCAEP Based on sessions Evalutaion of access decisions RISC disaster mitigation security risks and inicdnets Delivery methods are push (RFC 8935) or poll (RFC 8936).\nThere is also an IETF draft for SCIM Events.\nhtps://caep.dev\nImplementation in Keycloak with pull request 43950 Custom login when receiving events. Next step will be transmitter support.\nQuestions \u0026amp; thoughts 🤔 Does the CAPE profile make OpenID connect session managment obsolete? Answer: No, different use cases For SaaS, how is privacy of the user handled? In Keycloak is the logic on how to handle events configurable, if so how? Nextcloud as Identity Provider? SCIM Client Integration for Multi-Platform Collaboration Nextcloud X OpenProject\nUse scim for automated identity information exchange.\nAGPLv3: The only sensible license option for NC apps according to the speaker .\nQuestions \u0026amp; thoughts 🤔 Why not use a dedicated IDP? Now I am a bit confused on what exactly the difference is between the SCIM client and server. I should do a deep div on SCIM.\nKeeping applications secure by evolving OAuth 2.0 and OpenID Connect FAPI 2.0 was published in 2025 targeting more than just banking (e-health, government).\nSecurity assumptions of FAPI 2.0 were well documented.\nhttps://openid.net/specs/fapi-attacker-model-2_0-final.html\nSecure your transport layer!\nTLS 1.2+ Check certificates DNSSEC Secure ciphers HTSTS OAuth best pratices\nTLS on all endpoints No ROPC No wildcards in redirct URIs Private key JWT client authentication (no public clients) Pushed Auth. request (PAR) PKCE with S256 Sender contrained tokesn (mTLS or DPoP) An API can respond to a API request with a DPoP nonce request. Adding an extra step to an API request, but improving security.\n🤔 I wonder if this is always required for DPoP or if the nonce is optional. The RFC says \u0026ldquo;An authorization server MAY supply a nonce value to be included by the client in DPoP proofs sent.\u0026rdquo; So I guess it\u0026rsquo;s optional. See RFC 9449 for details.\nKeycloak has builtin client profiles. Which enforces security requirements on clients. Enforced at config and runtime. Rules can be added to a custom profile.\nFunny way to convince development teams to keep clients secure: brownouts to speed up the process. Security with a whip!\nThere is a keycloak conference taking place in Amsterdam in March 2026.\nQuestions \u0026amp; thoughts 🤔 Error messages in the Keycloak admin UI suck. This could be something that can be improved by the community. If I felt more comfortable with the codebase I could pick it up.\nI wonder if the security profiles could be externalised, I have built scripts in the past to validate OAuth client configs against a set of security rules.\nInside ProConnect: Building a Modern Federated Identity Provider for Government Services ProConnect enables single login for grench government services (public servants, external users)\nLa Suite numerique a set of open source tools provided by the French Govt.\nDemo with one of the best: Visio for vidio confernces.\nUser gives email and ProConnect redirect to the correct underlying IDP. The designs of the webui\u0026rsquo;s are alligned. From FranceConnect to ProConnect\nProconnect has ~40 Idp\u0026rsquo;s!\nSP \u0026amp; Idp Mocks.\nhttp://www.dev-agentconnect.fr/\nIdentity borkering: Email domain name based routing.\nPasskey auht with AMR POP\nIdentity format for public servants in a professional context.\nTesting is free via Espace Parenaires.\nEasy install of ProConnect with Docker.\nOpen Repository on github\nQuestions \u0026amp; thoughts 🤔 If ProConnect is a fork of FranceConnect, is the infra / user database / \u0026hellip; also forked? IF ProConnect acts as an Identity Broker, how does it decide on the Idp to user? Is the user identified first? Yes, map of email domains to Idp. Privacy and Sovereignty in a Post Quantum Open World Kings \u0026amp; Serfs, Masers \u0026amp; Slaves. Closed source users are software slaves!\nBusiness people hat the word freedom (Choice, competition)\nSovereignty, not just for data but: Software, Networking, Technology.\nUsers need to control\nOne more consideration: Quantum Computing\n(re)encrypt data VPN\u0026rsquo;s -\u0026gt; QPN\u0026rsquo;s Need to move towards MFA We need a community of trusted people.\nFreedom Software RISC-V Architecture Now moved to swiss We need sovereign cloud that are security first.\nCorporta: Secure sentinel\nCommunity cloud: freedombox.org\nTiny server on SBC.\nAlso supports fediverse.party software for social networks.\nMFA: Hardwayre keys: need to use 2. Has to be open design:\ninspectable long life Working with solokeys an open-source FIDO2 security key.\nSUSEID - Sovereign IAM at SUSE How suse has tackled IAM landscape.\nLot\u0026rsquo;s of mergers: Multiple password providers, add-ons and bridges.\nThe ride for an average SUSE Employee\nOpen Jira: user +pass Open conflunece: user +pass Open build service: user +pass Bugziall: user +pass suse costuomer center: different prompt! Art21 of nis2 Dora art 5,9,10\n-\u0026gt; No SaaS for Auth.\nSelf hosting comes with costs, (ops, dc, \u0026hellip;)\nPatroni for HA PostgreSQL Garage for obj storage\nAuthentik IDP\nExisting projects: smallstep KanIDM\nNew projects:\nstepdance: certifiactes ldap SEBIN search + bind IDM Merge: Idm Aggregator \u0026amp; Dedup Credentials for Linux: Bringing Passkeys to the Linux desktop Passkeys are quite complex.\nPasskey = FIDO2 discoverable credential\nusernamesless \u0026amp; passwordless New FIDO2\nHybrid flow: Passkey on pohne (qr code) synced Passkeys Modern Passkeys\nPhones and password managers Default:\nGoogle Password manager iCloud keychain Third party: bitwaden oss requires credential provider API\n(synced creendials)\nSecurity keys still for entrprise\nLinux desktop needs platform api\u0026rsquo;s.\nInconsistent api: currently apps (browsers) implement UX themselves.\nContainerized (flatpak) apps\u0026rsquo; don\u0026rsquo;t have access to hardware api\u0026rsquo;s (workaround --device=all, enables origin bypass)\nSolution: a new Credentials api.\nD-Bus support for privileged and unprvilegd clients New componenents:\nlebwebauthn: CTAP/WebAuthn credentialsd Use of xdg-desktop portals for sandboxed apps.\nIn libauthn: TPM 2.0 (platform) is planned\nOpen Cahllenges:\nOrigin scoping: credentials for your origin should only be accessed by that origin. How do we determine origin App identity verification? Prividleged: any origin (browsers) unprvilegd: restricted to specific origin\nCockpit and passwordless login Cockpit authentication:\nPreferably PAM modules SSO, Kerberos, \u0026hellip; Flatpak app SSH keys are an example of passwordless but not usable in te browser.\nBased on WebAuthn,FIDO2,Passkeys\nensure origin authenticity web domain / hostname / realm differences. /.well-known-webauthn Can support multiple origins. Registering with the \u0026ldquo;Chromium virtual authenticator enviroment\u0026rdquo; for testing / demo.\nPasskey\nDiscoverable limited slots no username needed, user Non-discoverable doesn\u0026rsquo;t store on hardware Questions \u0026amp; thoughts 🤔 I should look further into discoverable vs Non-discoverable credentials on passkeys.\nFancy slides! I wonder what was used to create them.\nPasswordless authentication mechanisms from the GUI (GDM) GDM: Login on gnome (Password, Smartcard, Fingerprint)\nGnome shell renders the UI. Runs as GDM user To authenticate GDM calls PAM over private dbus servers.\nImproved UX: select auth. method.\nNew web login with OAuth device code flow.\nFingerprint only on lock screen.\nAvailable in SSSD 2.12.0\nTwo merge requests for GNOME 50\nFuture enhancements:\nembedded webview PAM conversation through fd Move GDM into systemd? Questions \u0026amp; thoughts 🤔 Someone asked a question on using SPIFFE which is used for workload authentication, I guess they were wondering if it\u0026rsquo;s possible to let an AI agent authenticate to a Linux machine with a gnome desktop this way?\nReduce attack surface or keep compatibility: lessons of sudo-rs and run0 transition plans US Govt. mandating secure software\nZero trust Secure software development Switch to modern languages Will take long time to transition (ZTA, Post-Quantum).\nHow to reduce attack surface?\nrun0 aims for a system without SUID polkit for AuthZ Reducing attack surface Sudo-rs: Switching to Rust\nMemory safety Thread safety Error handling Strong typing Large scale deployments FreeIPA can centrally manage sudo rules\nGeneric rules\nsudo added support for regexes Polkit action defintions are local XML-based files. Polkit authorziation rules are written in javascript, have to be local files.\nsudo-rs: missing features\nQuestions \u0026amp; thoughts 🤔 Is the goal of sudo-rs to have feature parity with sudo?\nI should look into how polkit handles fine grained authorziation.\nRust Devroom \u0026amp; Lightning Lightning Talks Rust Coreutils in Ubuntu: Yes, we rewrote /bin/true in Rust \u0026ndash; Here’s what really happened Pareto rules: 80 of the work takes 20 of the time\nWhat\u0026rsquo;s next.\nRewrite other GNU utilities.\nQuestions \u0026amp; thoughts 🤔 GPL debate: Is canonical just supporting this so they can get rid of GPL code in their distro?\nCONTRIBUTING.yaml CONTRIBUTING.md but machine readable\nstatus intentions support needs ECMA standarization track.\nhttps://www.tc54.org/contributing-yaml/\nMisconceptiosn heard at FOSDEM about CRA No fines for open source projects. You can take donations. Your employer won\u0026rsquo;t be liable if you as an employee work on foss Releasing FOSS does not mean that you need to fill in compliance documents. an open source steward can be useful, but is not required. The CRA does not require changes to project processes \u0026hellip; Dumb guide to smart TVs You pay for:\nads Automatic Content Recognition Send low quality screenshots to vendor. the netflix button Nu smart TV allows you to turn off all of the anti-features\ndont\u0026rsquo;t connect it to the internet hack your TV! body.build Wikipedia bring the best articles, what is the equivalent for fitness?\nDatabase of exercises Applications program creator calorie calculator \u0026hellip; https://body.build/\nPostgreSQL compatibility index Not everyone that claims to be PostgreSQL compatible actually is.\nSuite to test compatibility.\npacman cache server I\u0026rsquo;m not using Arch at the moment so I took no notes 😄.\nEU software patents via UPC ffii.org\nGUI vs TUI \u0026ndash; Why not both? Amazing!\nweb browser -\u0026gt; wayland -\u0026gt; terminal\nRender browser directly to terminal\nNot interested in smart but funny. https://github.com/dextero/smithay\nGit for email Using a git repo to represent emails as files.\nRCL configuration language Extends JSON by adding variables functions loops \u0026hellip;\nCan also be used to query\n🤔 I wonder what the difference is with Jsonnet.\nGitify your life - 14 years later Etckeeper, bup, ikiwiki, git-annex, metamonger, vcsh, mr, zsh.\nMain track Open Source Security in spite of AI Took no notes.\nhttps://daniel.haxx.se/blog/2026/02/03/open-source-security-in-spite-of-ai/\nClosing FOSDEM 2026 If we lose our democracies Open Source is irrelevant and goes away!\n\u0026ndash; RichiH\nTalks I would still like to watch later There were a whole lot of talks that I was not able to watch. Luckily talks at FOSDEM are recorded \u0026amp; avaiable on video.fosdem.org!\nListed talks.\n","permalink":"https://notes.robinvanhove.me/posts/2026/fosdem-2/","summary":"\u003cp\u003e\u003ca href=\"/posts/2026/fosdem-1\"\u003eNotes on day 1\u003c/a\u003e\u003c/p\u003e\n\u003ch2 id=\"identity-and-access-management-devroom\"\u003eIdentity and Access Management Devroom\u003c/h2\u003e\n\u003cblockquote\u003e\n\u003cp\u003eThis room is cursed.\u003c/p\u003e\n\u003cp\u003e\u0026ndash; \u003cem\u003eThe video volunteer when entering the room in the morning.\u003c/em\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eDay two stared of great with a some great presentations in the IAM devroom. I\nwoke up early so I could get a seat on the front row and was happy that I did.\u003c/p\u003e\n\u003cp\u003e\u003cimg loading=\"lazy\" src=\"/posts/2026/fosdem-2/thomas.jpg\" type=\"\" alt=\"Thomas Darimont giving a presentation on OpenID\u0026rsquo;s shared signals framework.\"  /\u003e\n\u003cem\u003eThomas Darimont giving a presentation on OpenID\u0026rsquo;s shared signals framework.\u003c/em\u003e\u003c/p\u003e","title":"FOSDEM 2026 Day 2"},{"content":"Broken Object Level Authorization is the number one in OWASP\u0026rsquo;s API security top 10.\nAPIs tend to expose endpoints that handle object identifiers, creating a wide attack surface of Object Level Access Control issues. Object level authorization checks should be considered in every function that accesses a data source using an ID from the user.\nWhat is Authorization? Decide if an action can be taken.\nCan Alice view document #123? Can Alice view document #123 at 16:30 on Tuesday, 11 June, 2024? Can Bob edit document #123 in China? Can Bob edit document #123 in China, when authenticated with MFA? Can a manager create document #456 We can always identify the following:\nSubject, the user or thing trying to take an action Type \u0026amp; identifier E.g. user:Alice, application:123 Or properties of the subject E.g. manager Action, the thing the subject is trying to do E.g. view, edit Resource, the target of the action Type \u0026amp; identifier E.g. document:#123 Context, any additional information that can influence the decision. E.g. time, location, authentication method. Additionally we often want to search based on the authorization decisions. A search is essentially a decision with one or more free variables.\nWhich documents can Alice view? Who can view document 123? What actions can Alice perform on document 123 on Tuesday, June 11, 2024? Access control models Access control models can be separated by their specificity.\nCoarse-grained access control models Role-based access control (RBAC), is the most common access control model. A subject is assigned to a role and depending on their role the application decides whether to allow access.\nCoarse grained access control models such as RBAC are easy to implement.\nIt might look like they are easy to manage but in practice group, entitlements and roles become a mess.\nFine-grained access context models Often this is implemented by mapping specific actions on resources to entitlements (arbitrary strings) and combining those in a role and assigning those to a group of subjects.\nRelationship-based access control (ReBAC) looks at the relation of resources and subjects. Essentially it looks at the graph of resources and subjects to decides whether an action is allowed.\nFrom: https://docs.aserto.com/docs/authorization-basics/authorization-models/rebac\nAttribute-based access control (ABAC), compares attributes assigned to a subject and resource to decide if an action is allowed.\nPolicy-based access control (PBAC), the most generic model. A policy can be any evaluation of any computer program. Often specific domain specific languages are used to describe the policy.\nHybrid models Coarse-grained and fine-grained can be combined. For example an API gateway or application proxy can check if a user is allowed to access a service using RBAC but the service can use a more fine-grained model such as ReBAC to check if specific actions are allowed on a resource.\nThis approach can improve performance and provide better (mutli-layered) security.\nGoogle\u0026rsquo;s Zanzibar Determining whether online users are authorized to access digital objects is central to preserving privacy. This paper presents the design, implementation, and deployment of Zanzibar, a global system for storing and evaluating access control lists. Zanzibar provides a uniform data model and configuration language for expressing a wide range of access control policies from hundreds of client services at Google, including Calendar, Cloud, Drive, Maps, Photos, and YouTube. Its authorization decisions respect causal ordering of user actions and thus provide external consistency amid changes to access control lists and object contents. Zanzibar scales to trillions of access control lists and millions of authorization requests per second to support services used by billions of people. It has maintained 95th-percentile latency of less than 10 milliseconds and availability of greater than 99.999% over 3 years of production use.\nhttps://research.google/pubs/zanzibar-googles-consistent-global-authorization-system/\nAuthorization Policies These describe the rules. From Nist\u0026rsquo;s guide to ABAC:\nNatural Language Policy (NLP): Statements governing management and access of enterprise objects. NLPs are human expressions that can be translated to machine-enforceable access control policies.\nDigital Policy (DP): Access control rules that compile directly into machine executable codes or signals. Subject/object attributes, operations, and environment conditions are the fundamental elements of DP, the building blocks of DP rules, which are enforced by an access control mechanism.\nMetapolicy (MP): A policy about policies, or policy for managing policies, such as assignment of priorities and resolution of conflicts between DPs or other MPs.\nDigital policies are the real software implementation of the policy. These are often described using A DCL XACML, ALFA, Rego, Oso Polar.\nA policy evaluation engine takes the authorization policy, and the authorization request and outputs a decision.\nDigital Policy example with Rego Rego is currently the most popular and open language for to define policies, it was developed for the OPA policy engine and is based on the datalog programming language.\nRego is a declerative programming language, made for writing authorization policies.\nThe following is an example from the Rego playground.\nPolicy:\npackage app.abac default allow := false allow if user_is_owner allow if { user_is_employee action_is_read } allow if { user_is_employee user_is_senior action_is_update } allow if { user_is_customer action_is_read not pet_is_adopted } user_is_owner if data.user_attributes[input.user].title == \u0026#34;owner\u0026#34; user_is_employee if data.user_attributes[input.user].title == \u0026#34;employee\u0026#34; user_is_customer if data.user_attributes[input.user].title == \u0026#34;customer\u0026#34; user_is_senior if data.user_attributes[input.user].tenure \u0026gt; 8 action_is_read if input.action == \u0026#34;read\u0026#34; action_is_update if input.action == \u0026#34;update\u0026#34; pet_is_adopted if data.pet_attributes[input.resource].adopted == true Data:\n{ \u0026#34;user_attributes\u0026#34;: { \u0026#34;alice\u0026#34;: { \u0026#34;tenure\u0026#34;: 20, \u0026#34;title\u0026#34;: \u0026#34;owner\u0026#34; } }, \u0026#34;pet_attributes\u0026#34;: { \u0026#34;dog123\u0026#34;: { \u0026#34;adopted\u0026#34;: true, \u0026#34;age\u0026#34;: 2, \u0026#34;breed\u0026#34;: \u0026#34;terrier\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;toto\u0026#34; } } } Input:\n{ \u0026#34;user\u0026#34;: \u0026#34;alice\u0026#34;, \u0026#34;action\u0026#34;: \u0026#34;read\u0026#34;, \u0026#34;resource\u0026#34;: \u0026#34;dog123\u0026#34; } Output:\n{ \u0026#34;action_is_read\u0026#34;: true, \u0026#34;allow\u0026#34;: true, \u0026#34;pet_is_adopted\u0026#34;: true, \u0026#34;user_is_owner\u0026#34;: true, \u0026#34;user_is_senior\u0026#34;: true } Externalized Authorization Architecture Often the authorization is implemented in the application itself, either hard-coded or trough configurations. But this approach has shortcomings in large, distributed and dynamic systems.\nPolicy (interpretation) consistency Reuse of implementations Policy administration (version control, deployments) More difficult to improve performance For these reasons it is often decided to externalize authorization out of the application.\nThe simplest approach to externalize authorization is to centralize it in one system. But there are other patterns possible, more on that later.\nDefined in XACML and Nist\u0026rsquo;s guide to ABAC\nBy Axiomatics - Axiomatics, CC BY 3.0, https://commons.wikimedia.org/w/index.php?curid=48397652\nXACML Dataflow Diagram, image from OASIS spec.\nPolicy Decision point components The PDP is shown as one component in the XACML architecture but we can distinguish multiple subcomponents.\nPolicy Engine is the component responsible for actually evaluating the policy and making a decision.\nPDP Interface or API implements how the PEP can send queries to th PDP. Often based upon HTTP and JSON but gRCP. Every PDP implementation uses a different kind of (often proprietary API). But there is a process ongoing by the OpenID foundation to standerize an interface called AuthZEN.\nThe data plane is responsible for gathering data form the relevant PIP\u0026rsquo;s. E.g. user \u0026amp; resource attributes. The data plane can also concern itself with caching and structuring the data in a performant data structure such as a graph for performant policy evaluation.\nThe data plane can exist completely separate from the PDP (any databse or API can be used). But many implementations choose to tightly couple the PDP and PIP for optimal performance.\nA policy control plane is required to distribute updates to policies the PDP\u0026rsquo;s as soon as they are changed. The control plane is the glue between the PAP and PDP. The control plane can also provide information about the configuration of the data plane, such as the location of the PIP\u0026rsquo;s.\nFancy Archtiectural patterns OPAL Architecture, from https://docs.opal.ac/overview/architecture/\nFully centralized service Per-tenant Per application As a library Sidecar container Policy administration (PAP) Many solutions provide powerful interfaces to manage policies.\nPolicy creation interface. The digital policy can be written as computer program using any text editor or IDE. But many implementations provide interfaces to make it easy to use for less technical people.\nVersion control is essential for policy management. Often software VCS such as git ore often used because most operations are already using it. But sometimes authorization services implement their own version control, tightly coupled with the ui of the PAP.\nPolicy distribution trough the control plane, just like any program the authorization policies require some form of continous deployent, depending on the chosen architecture this can become very complex, requiring deployment to multiple PDP\u0026rsquo;s without having downtime.\nTesting should also be considered, the digital policy is a computer program like any other and there should exist \u0026lsquo;unit\u0026rsquo; test to ensure that the policies (and any for changes) behave as expected. Issues in a policy can have huge consequences for the security of the system.\nAuthZEN The OpenID foudnation has identified the need for a standardized interface for authorization, similar to their OpenID connect standard for authentication.\nhttps://openid.github.io/authzen/\nAuthZEN is essentially an API specification standardizing the contract between PDP and PEP. It contains two API\u0026rsquo;s.\nAccess Evaluation(s) API Search API Access Evaluation API Modified example from the AuthZEN draft.\nThe access evaluation API returns the decision as a boolean, but can also provide some context.\nAn alternative endpoint is also defined that can evaluate multiple decisions in one request.\nRequest:\nPOST /access/v1/evaluation HTTP/1.1 Host: pdp.example.com Content-Type: application/json Authorization: Bearer \u0026lt;myoauthtoken\u0026gt; X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716 { \u0026#34;subject\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;user\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;alice@example.com\u0026#34; }, \u0026#34;resource\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;document\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;1\u0026#34; }, \u0026#34;action\u0026#34;: { \u0026#34;name\u0026#34;: \u0026#34;edit\u0026#34; }, \u0026#34;context\u0026#34;: { \u0026#34;time\u0026#34;: \u0026#34;1985-10-26T01:22-07:00\u0026#34; } } Response:\nHTTP/1.1 OK Content-Type: application/json X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716 { \u0026#34;decision\u0026#34;: false, \u0026#34;context\u0026#34;: { \u0026#34;reason\u0026#34;: \u0026#34;Subject is a viewer of the resource\u0026#34; } } Search API Example form the draft.\nThe search API can search for subjects, actions and resources.\nIt also specifies pagination which is which is essential for scalability.\nRequest:\nPOST /access/v1/search/resource HTTP/1.1 Host: pdp.example.com Content-Type: application/json Authorization: Bearer \u0026lt;myoauthtoken\u0026gt; X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716 { \u0026#34;subject\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;user\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;alice@example.com\u0026#34; }, \u0026#34;action\u0026#34;: { \u0026#34;name\u0026#34;: \u0026#34;can_read\u0026#34; }, \u0026#34;resource\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;account\u0026#34; } } Response:\nHTTP/1.1 OK Content-Type: application/json X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716 { \u0026#34;page\u0026#34;: { \u0026#34;next_token\u0026#34;: \u0026#34;a3M9NDU2O3N6PTI=\u0026#34; }, \u0026#34;results\u0026#34;: [ { \u0026#34;type\u0026#34;: \u0026#34;account\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;123\u0026#34; }, { \u0026#34;type\u0026#34;: \u0026#34;account\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;456\u0026#34; } ] } OAuth Rich Authorization Requests There also exists an extension to famout OAuth authorization framework to implement FGA.\nIdeal for when user interaction (permission) is required before allowing a service to take an action. Or for cross-domain use cases.\nFrom RFC 9396: OAuth 2.0 Rich Authorization Requests:\nThis specification introduces a new parameter authorization_details that allows clients to specify their fine-grained authorization requirements using the expressiveness of JSON data structures.\nFor example, an authorization request for a credit transfer (designated as \u0026ldquo;payment initiation\u0026rdquo; in several open banking initiatives) can be represented using a JSON object like this:\n{ \u0026#34;type\u0026#34;: \u0026#34;payment_initiation\u0026#34;, \u0026#34;locations\u0026#34;: [ \u0026#34;https://example.com/payments\u0026#34; ], \u0026#34;instructedAmount\u0026#34;: { \u0026#34;currency\u0026#34;: \u0026#34;EUR\u0026#34;, \u0026#34;amount\u0026#34;: \u0026#34;123.50\u0026#34; }, \u0026#34;creditorName\u0026#34;: \u0026#34;Merchant A\u0026#34;, \u0026#34;creditorAccount\u0026#34;: { \u0026#34;bic\u0026#34;:\u0026#34;ABCIDEFFXXX\u0026#34;, \u0026#34;iban\u0026#34;: \u0026#34;DE02100100109307118603\u0026#34; }, \u0026#34;remittanceInformationUnstructured\u0026#34;: \u0026#34;Ref Number Merchant\u0026#34; } From RFC 9396: Example of an Authorization Request for a Credit Transfer\nThe new enemy problem Audit logs An advantage is centralizing the authorization is that it also become easier to centralize the decision logs. These are very useful for auditing.\nProjects and products Open source with commercial offering All most all (production ready) open source implementations of FGA are backed by a commercial company providing a product based upon the open-source project.\nOpen source / Commercial product.\nOPA / Styra enterprise OPA \u0026amp; DAS OPAL / Permit.io Aserto / Topaz spiceDB / AuhtZed OpenFGA / Auth0 (Okta) FGA Casbin / Casdoor Proprietary Several companies also sell fully closed source authorization services.\nOso Security Ping Authorize AWS Cedar Axiomatics Permify Cerbos Sources \u0026amp; further reading https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/ https://idpro.org/the-state-of-the-union-of-authorization/ https://www.permit.io/blog/what-is-fine-grained-authorization-fga https://openid.net/wg/authzen/ https://openid.github.io/authzen/ https://www.feldera.com/blog/fine-grained-authorization https://docs.aserto.com/docs/authorization-basics https://datatracker.ietf.org/doc/html/rfc9396 ","permalink":"https://notes.robinvanhove.me/notes/fga/","summary":"\u003cp\u003eBroken Object Level Authorization is the number one in OWASP\u0026rsquo;s API security\ntop 10.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eAPIs tend to expose endpoints that handle object identifiers, creating a wide\nattack surface of Object Level Access Control issues. Object level\nauthorization checks should be considered in every function that accesses a\ndata source using an ID from the user.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch2 id=\"what-is-authorization\"\u003eWhat is Authorization?\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eDecide\u003c/strong\u003e if an action can be taken.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eCan Alice view document #123?\u003c/li\u003e\n\u003cli\u003eCan Alice view document #123 at 16:30 on Tuesday, 11 June, 2024?\u003c/li\u003e\n\u003cli\u003eCan Bob edit document #123 in China?\u003c/li\u003e\n\u003cli\u003eCan Bob edit document #123 in China, when authenticated with MFA?\u003c/li\u003e\n\u003cli\u003eCan a manager create document #456\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eWe can always identify the following:\u003c/p\u003e","title":"Fine-Grained Authorization (FGA)"},{"content":"Broken Object Level Authorization is the number one in OWASP\u0026rsquo;s API security top 10.\nAPIs tend to expose endpoints that handle object identifiers, creating a wide attack surface of Object Level Access Control issues. Object level authorization checks should be considered in every function that accesses a data source using an ID from the user.\nWhat is Authorization? Decide if an action can be taken.\nCan Alice view document #123? Can Alice view document #123 at 16:30 on Tuesday, 11 June, 2024? Can Bob edit document #123 in China? Can Bob edit document #123 in China, when authenticated with MFA? Can a manager create document #456 We can always identify the following:\nSubject, the user or thing trying to take an action Type \u0026amp; identifier E.g. user:Alice, application:123 Or properties of the subject E.g. manager Action, the thing the subject is trying to do E.g. view, edit Resource, the target of the action Type \u0026amp; identifier E.g. document:#123 Context, any additional information that can influence the decision. E.g. time, location, authentication method. Additionally we often want to search based on the authorization decisions. A search is essentially a decision with one or more free variables.\nWhich documents can Alice view? Who can view document 123? What actions can Alice perform on document 123 on Tuesday, June 11, 2024? Access control models Access control models can be separated by their specificity.\nCoarse-grained access control models Role-based access control (RBAC), is the most common access control model. A subject is assigned to a role and depending on their role the application decides whether to allow access.\nCoarse grained access control models such as RBAC are easy to implement.\nIt might look like they are easy to manage but in practice group, entitlements and roles become a mess.\nFine-grained access context models Often this is implemented by mapping specific actions on resources to entitlements (arbitrary strings) and combining those in a role and assigning those to a group of subjects.\nRelationship-based access control (ReBAC) looks at the relation of resources and subjects. Essentially it looks at the graph of resources and subjects to decides whether an action is allowed.\nFrom: https://docs.aserto.com/docs/authorization-basics/authorization-models/rebac\nAttribute-based access control (ABAC), compares attributes assigned to a subject and resource to decide if an action is allowed.\nPolicy-based access control (PBAC), the most generic model. A policy can be any evaluation of any computer program. Often specific domain specific languages are used to describe the policy.\nHybrid models Coarse-grained and fine-grained can be combined. For example an API gateway or application proxy can check if a user is allowed to access a service using RBAC but the service can use a more fine-grained model such as ReBAC to check if specific actions are allowed on a resource.\nThis approach can improve performance and provide better (mutli-layered) security.\nGoogle\u0026rsquo;s Zanzibar Determining whether online users are authorized to access digital objects is central to preserving privacy. This paper presents the design, implementation, and deployment of Zanzibar, a global system for storing and evaluating access control lists. Zanzibar provides a uniform data model and configuration language for expressing a wide range of access control policies from hundreds of client services at Google, including Calendar, Cloud, Drive, Maps, Photos, and YouTube. Its authorization decisions respect causal ordering of user actions and thus provide external consistency amid changes to access control lists and object contents. Zanzibar scales to trillions of access control lists and millions of authorization requests per second to support services used by billions of people. It has maintained 95th-percentile latency of less than 10 milliseconds and availability of greater than 99.999% over 3 years of production use.\nhttps://research.google/pubs/zanzibar-googles-consistent-global-authorization-system/\nAuthorization Policies These describe the rules. From Nist\u0026rsquo;s guide to ABAC:\nNatural Language Policy (NLP): Statements governing management and access of enterprise objects. NLPs are human expressions that can be translated to machine-enforceable access control policies.\nDigital Policy (DP): Access control rules that compile directly into machine executable codes or signals. Subject/object attributes, operations, and environment conditions are the fundamental elements of DP, the building blocks of DP rules, which are enforced by an access control mechanism.\nMetapolicy (MP): A policy about policies, or policy for managing policies, such as assignment of priorities and resolution of conflicts between DPs or other MPs.\nDigital policies are the real software implementation of the policy. These are often described using A DCL XACML, ALFA, Rego, Oso Polar.\nA policy evaluation engine takes the authorization policy, and the authorization request and outputs a decision.\nDigital Policy example with Rego Rego is currently the most popular and open language for to define policies, it was developed for the OPA policy engine and is based on the datalog programming language.\nRego is a declerative programming language, made for writing authorization policies.\nThe following is an example from the Rego playground.\nPolicy:\npackage app.abac default allow := false allow if user_is_owner allow if { user_is_employee action_is_read } allow if { user_is_employee user_is_senior action_is_update } allow if { user_is_customer action_is_read not pet_is_adopted } user_is_owner if data.user_attributes[input.user].title == \u0026#34;owner\u0026#34; user_is_employee if data.user_attributes[input.user].title == \u0026#34;employee\u0026#34; user_is_customer if data.user_attributes[input.user].title == \u0026#34;customer\u0026#34; user_is_senior if data.user_attributes[input.user].tenure \u0026gt; 8 action_is_read if input.action == \u0026#34;read\u0026#34; action_is_update if input.action == \u0026#34;update\u0026#34; pet_is_adopted if data.pet_attributes[input.resource].adopted == true Data:\n{ \u0026#34;user_attributes\u0026#34;: { \u0026#34;alice\u0026#34;: { \u0026#34;tenure\u0026#34;: 20, \u0026#34;title\u0026#34;: \u0026#34;owner\u0026#34; } }, \u0026#34;pet_attributes\u0026#34;: { \u0026#34;dog123\u0026#34;: { \u0026#34;adopted\u0026#34;: true, \u0026#34;age\u0026#34;: 2, \u0026#34;breed\u0026#34;: \u0026#34;terrier\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;toto\u0026#34; } } } Input:\n{ \u0026#34;user\u0026#34;: \u0026#34;alice\u0026#34;, \u0026#34;action\u0026#34;: \u0026#34;read\u0026#34;, \u0026#34;resource\u0026#34;: \u0026#34;dog123\u0026#34; } Output:\n{ \u0026#34;action_is_read\u0026#34;: true, \u0026#34;allow\u0026#34;: true, \u0026#34;pet_is_adopted\u0026#34;: true, \u0026#34;user_is_owner\u0026#34;: true, \u0026#34;user_is_senior\u0026#34;: true } Externalized Authorization Architecture Often the authorization is implemented in the application itself, either hard-coded or trough configurations. But this approach has shortcomings in large, distributed and dynamic systems.\nPolicy (interpretation) consistency Reuse of implementations Policy administration (version control, deployments) More difficult to improve performance For these reasons it is often decided to externalize authorization out of the application.\nThe simplest approach to externalize authorization is to centralize it in one system. But there are other patterns possible, more on that later.\nDefined in XACML and Nist\u0026rsquo;s guide to ABAC\nBy Axiomatics - Axiomatics, CC BY 3.0, https://commons.wikimedia.org/w/index.php?curid=48397652\nXACML Dataflow Diagram, image from OASIS spec.\nPolicy Decision point components The PDP is shown as one component in the XACML architecture but we can distinguish multiple subcomponents.\nPolicy Engine is the component responsible for actually evaluating the policy and making a decision.\nPDP Interface or API implements how the PEP can send queries to th PDP. Often based upon HTTP and JSON but gRCP. Every PDP implementation uses a different kind of (often proprietary API). But there is a process ongoing by the OpenID foundation to standerize an interface called AuthZEN.\nThe data plane is responsible for gathering data form the relevant PIP\u0026rsquo;s. E.g. user \u0026amp; resource attributes. The data plane can also concern itself with caching and structuring the data in a performant data structure such as a graph for performant policy evaluation.\nThe data plane can exist completely separate from the PDP (any databse or API can be used). But many implementations choose to tightly couple the PDP and PIP for optimal performance.\nA policy control plane is required to distribute updates to policies the PDP\u0026rsquo;s as soon as they are changed. The control plane is the glue between the PAP and PDP. The control plane can also provide information about the configuration of the data plane, such as the location of the PIP\u0026rsquo;s.\nFancy Archtiectural patterns OPAL Architecture, from https://docs.opal.ac/overview/architecture/\nFully centralized service Per-tenant Per application As a library Sidecar container Policy administration (PAP) Many solutions provide powerful interfaces to manage policies.\nPolicy creation interface. The digital policy can be written as computer program using any text editor or IDE. But many implementations provide interfaces to make it easy to use for less technical people.\nVersion control is essential for policy management. Often software VCS such as git ore often used because most operations are already using it. But sometimes authorization services implement their own version control, tightly coupled with the ui of the PAP.\nPolicy distribution trough the control plane, just like any program the authorization policies require some form of continous deployent, depending on the chosen architecture this can become very complex, requiring deployment to multiple PDP\u0026rsquo;s without having downtime.\nTesting should also be considered, the digital policy is a computer program like any other and there should exist \u0026lsquo;unit\u0026rsquo; test to ensure that the policies (and any for changes) behave as expected. Issues in a policy can have huge consequences for the security of the system.\nAuthZEN The OpenID foudnation has identified the need for a standardized interface for authorization, similar to their OpenID connect standard for authentication.\nhttps://openid.github.io/authzen/\nAuthZEN is essentially an API specification standardizing the contract between PDP and PEP. It contains two API\u0026rsquo;s.\nAccess Evaluation(s) API Search API Access Evaluation API Modified example from the AuthZEN draft.\nThe access evaluation API returns the decision as a boolean, but can also provide some context.\nAn alternative endpoint is also defined that can evaluate multiple decisions in one request.\nRequest:\nPOST /access/v1/evaluation HTTP/1.1 Host: pdp.example.com Content-Type: application/json Authorization: Bearer \u0026lt;myoauthtoken\u0026gt; X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716 { \u0026#34;subject\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;user\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;alice@example.com\u0026#34; }, \u0026#34;resource\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;document\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;1\u0026#34; }, \u0026#34;action\u0026#34;: { \u0026#34;name\u0026#34;: \u0026#34;edit\u0026#34; }, \u0026#34;context\u0026#34;: { \u0026#34;time\u0026#34;: \u0026#34;1985-10-26T01:22-07:00\u0026#34; } } Response:\nHTTP/1.1 OK Content-Type: application/json X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716 { \u0026#34;decision\u0026#34;: false, \u0026#34;context\u0026#34;: { \u0026#34;reason\u0026#34;: \u0026#34;Subject is a viewer of the resource\u0026#34; } } Search API Example form the draft.\nThe search API can search for subjects, actions and resources.\nIt also specifies pagination which is which is essential for scalability.\nRequest:\nPOST /access/v1/search/resource HTTP/1.1 Host: pdp.example.com Content-Type: application/json Authorization: Bearer \u0026lt;myoauthtoken\u0026gt; X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716 { \u0026#34;subject\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;user\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;alice@example.com\u0026#34; }, \u0026#34;action\u0026#34;: { \u0026#34;name\u0026#34;: \u0026#34;can_read\u0026#34; }, \u0026#34;resource\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;account\u0026#34; } } Response:\nHTTP/1.1 OK Content-Type: application/json X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716 { \u0026#34;page\u0026#34;: { \u0026#34;next_token\u0026#34;: \u0026#34;a3M9NDU2O3N6PTI=\u0026#34; }, \u0026#34;results\u0026#34;: [ { \u0026#34;type\u0026#34;: \u0026#34;account\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;123\u0026#34; }, { \u0026#34;type\u0026#34;: \u0026#34;account\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;456\u0026#34; } ] } OAuth Rich Authorization Requests There also exists an extension to famout OAuth authorization framework to implement FGA.\nIdeal for when user interaction (permission) is required before allowing a service to take an action. Or for cross-domain use cases.\nFrom RFC 9396: OAuth 2.0 Rich Authorization Requests:\nThis specification introduces a new parameter authorization_details that allows clients to specify their fine-grained authorization requirements using the expressiveness of JSON data structures.\nFor example, an authorization request for a credit transfer (designated as \u0026ldquo;payment initiation\u0026rdquo; in several open banking initiatives) can be represented using a JSON object like this:\n{ \u0026#34;type\u0026#34;: \u0026#34;payment_initiation\u0026#34;, \u0026#34;locations\u0026#34;: [ \u0026#34;https://example.com/payments\u0026#34; ], \u0026#34;instructedAmount\u0026#34;: { \u0026#34;currency\u0026#34;: \u0026#34;EUR\u0026#34;, \u0026#34;amount\u0026#34;: \u0026#34;123.50\u0026#34; }, \u0026#34;creditorName\u0026#34;: \u0026#34;Merchant A\u0026#34;, \u0026#34;creditorAccount\u0026#34;: { \u0026#34;bic\u0026#34;:\u0026#34;ABCIDEFFXXX\u0026#34;, \u0026#34;iban\u0026#34;: \u0026#34;DE02100100109307118603\u0026#34; }, \u0026#34;remittanceInformationUnstructured\u0026#34;: \u0026#34;Ref Number Merchant\u0026#34; } From RFC 9396: Example of an Authorization Request for a Credit Transfer\nThe new enemy problem Audit logs An advantage is centralizing the authorization is that it also become easier to centralize the decision logs. These are very useful for auditing.\nProjects and products Open source with commercial offering All most all (production ready) open source implementations of FGA are backed by a commercial company providing a product based upon the open-source project.\nOpen source / Commercial product.\nOPA / Styra enterprise OPA \u0026amp; DAS OPAL / Permit.io Aserto / Topaz spiceDB / AuhtZed OpenFGA / Auth0 (Okta) FGA Casbin / Casdoor Proprietary Several companies also sell fully closed source authorization services.\nOso Security Ping Authorize AWS Cedar Axiomatics Permify Cerbos Sources \u0026amp; further reading https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/ https://idpro.org/the-state-of-the-union-of-authorization/ https://www.permit.io/blog/what-is-fine-grained-authorization-fga https://openid.net/wg/authzen/ https://openid.github.io/authzen/ https://www.feldera.com/blog/fine-grained-authorization https://docs.aserto.com/docs/authorization-basics https://datatracker.ietf.org/doc/html/rfc9396 ","permalink":"https://notes.robinvanhove.me/notes/test2x/","summary":"\u003cp\u003eBroken Object Level Authorization is the number one in OWASP\u0026rsquo;s API security\ntop 10.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eAPIs tend to expose endpoints that handle object identifiers, creating a wide\nattack surface of Object Level Access Control issues. Object level\nauthorization checks should be considered in every function that accesses a\ndata source using an ID from the user.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch2 id=\"what-is-authorization\"\u003eWhat is Authorization?\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eDecide\u003c/strong\u003e if an action can be taken.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eCan Alice view document #123?\u003c/li\u003e\n\u003cli\u003eCan Alice view document #123 at 16:30 on Tuesday, 11 June, 2024?\u003c/li\u003e\n\u003cli\u003eCan Bob edit document #123 in China?\u003c/li\u003e\n\u003cli\u003eCan Bob edit document #123 in China, when authenticated with MFA?\u003c/li\u003e\n\u003cli\u003eCan a manager create document #456\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eWe can always identify the following:\u003c/p\u003e","title":"Fine-Grained Authorization (FGA)"},{"content":"What is MFA Multi-factor authentication (MFA) is a security process that requires users to verify their identity using two or more distinct factors. Each factor can be from one of the following categories:\nSomething you know (e.g., a password) Something you have (e.g., a security token or mobile device) Something you are (e.g., a biometric such as fingerprint or face recognition) For an authentication method to be secure, it should validate at least two factors.\nBusiness Value Multi-factor authentication (MFA) delivers critical business value by significantly strengthening security and reducing the risk of data breaches, phishing, and credential theft, even if passwords are compromised. This protection safeguards not only sensitive company and customer data but also preserves customer trust and brand reputation, which are invaluable assets in today’s digital economy. As remote and flexible work becomes standard, MFA ensures secure access to company systems from any location, enabling productivity without sacrificing security. Beyond risk reduction, MFA also drives cost savings by minimizing fraud, security incidents, and IT support overhead, while integrating seamlessly with existing identity management systems to streamline operations and enhance efficiency. In essence, MFA is a strategic investment that secures assets, supports modern work environments, and protects your bottom line.\nAuthentication methods Why multiple options Offering multiple MFA methods directly addresses both user experience and operational resilience. Users have different preferences and access to devices. Some may prefer the convenience of an authenticator app, while others rely on SMS or biometrics. By providing choices, you reduce friction and increase adoption rates, which is critical for widespread security compliance. At the same time, redundancy ensures that if a user loses access to one method (like a misplaced phone), they aren’t locked out of their account and can fall back on an alternative, such as email verification or a hardware token. This not only keeps productivity high but also aligns with industry best practices and regulatory requirements, helping your product meet security standards without sacrificing usability. In short, it’s about balancing strong security with a seamless experience, which ultimately builds trust and reduces support overhead. idpro-mfa-for-humans\nPasskey (WebAuthn / FIDO2) |\u0026mdash;\u0026mdash;\u0026mdash;-|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;-| | Factors | - Something you have (device) | | | - Somehting you know (PIN) |\n- Somethign you are (Biometric) Security Very High \u0026mdash;\u0026mdash;\u0026mdash;- \u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;- Features - Passwordless - Usernameless - Phising resistant \u0026mdash;\u0026mdash;\u0026mdash;- \u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;- Passkeys are a modern, user-friendly, and phishing-resistant authentication method designed to replace passwords entirely. Built on WebAuthn and FIDO2 standards, passkeys enable passwordless and usernameless logins, relying instead on cryptographic keys stored on the user’s device (e.g., smartphone, laptop, or security key). They simplify the user experience by eliminating the need to remember or enter credentials, while also providing stronger security than traditional passwords.\nThe AAGUID (Authenticator Attestation GUID) identifies the passkey provider, use this to display a user-friendly name (e.g., \u0026ldquo;iPhone Passkey\u0026rdquo; for better clarity and management.\nSynced passkeys are stored encrypted in the cloud and automatically synchronized across a user’s registered devices, such as through iCloud Keychain or Google Password Manager. This allows users to log in passwordlessly from any of their trusted devices, offering convenience and flexibility.\nEssentially passkeys act like a direct interface between the server and the password manager.\nDevice-bound passkeys are permanently tied to a single device, such as a smartphone, laptop, or hardware security key. They cannot be exported or synced, providing stronger security by ensuring the private key never leaves the device.\nHardware security keys could be provisioned and distributed amongst the users. But this can be expense and time consuming. Most often companies choose to let the user provision their own security key, then it can also be used to access multiple services.\nThe most known hardware security key is the yubikey, but sold by many vendor such as OneSpan.\nTOTP |\u0026mdash;\u0026mdash;\u0026mdash;-|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026ndash;|\nFactors - Something you have (device) Security Medium \u0026mdash;\u0026mdash;\u0026mdash;- \u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026ndash; Features - Commonly used \u0026mdash;\u0026mdash;\u0026mdash;- \u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026ndash; TOTP (Time-based One-Time Passcode) is a temporary, time-sensitive passcode generated by an algorithm using the current time and a shared secret key. Each code is valid only for a short period (usually 30 seconds), adding an extra layer of security for authentication.\nOATH (Initiative for Open Authentication) is an industry standard that defines protocols for TOTP. It ensures compatibility and interoperability between servers and authenticator apps. It is supported by all authenticator apps such as:\nAegis Authenticator Google Authenticator Microsoft Authenticator To set up TOTP, users scan a QR code with their authenticator app and enter the generated code to confirm it works. On mobile devices, since scanning a QR code displayed on the same screen isn’t practical, use an otpauth:// URL to directly open and configure the authenticator app.\nThe authentication server should implement an OTP window, a setting to account for clock synchronization differences. This improves user experience by accepting codes generated in the previous, current, and next time intervals. This flexibility accounts for minor clock differences between the server and user device, reducing failed logins.\nSMS OTP (One time passcode) |\u0026mdash;\u0026mdash;\u0026mdash;-|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;-|\nFactors - Something you have (Phone with number) Security Low \u0026mdash;\u0026mdash;\u0026mdash;- \u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;- Features - Commonly used - No onboarding \u0026mdash;\u0026mdash;\u0026mdash;- \u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;- SMS OTP (One-Time Password) is a widely used multi-factor authentication method where a temporary, numeric code is sent to a user’s mobile phone via text message after they enter their username and password. This code, typically 4–6 digits long, is valid for a short period (often a few minutes) and must be entered into the login prompt to complete authentication.\nAttackers may perform SIM swaps to intercept SMS-based OTP codes.\nEmail OTP |\u0026mdash;\u0026mdash;\u0026mdash;-|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;-|\nFactors - Something you have (access to mailbox) Security Very low \u0026mdash;\u0026mdash;\u0026mdash;- \u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;- Features - Commonly used - No onboarding \u0026mdash;\u0026mdash;\u0026mdash;- \u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;- Email OTP sends a one-time code to the user’s inbox for login verification. If self service password reset is enabled, email OTP results in only one factor.\nMagic links a passwordless authentication method that sends users an URL, allowing them to log in securely by clicking the link instead of entering the OTP code. Consider using this to improve user experience in combination with the OTP code.\nMobile App Push notifications |\u0026mdash;\u0026mdash;\u0026mdash;-|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;|\nFactors - Something you have (smartphone with app) Security High \u0026mdash;\u0026mdash;\u0026mdash;- \u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash; Features - Easy to use \u0026mdash;\u0026mdash;\u0026mdash;- \u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash; Mobile App Push Notifications authenticate users by sending an approval push notification to a smartphone app. This method is user-friendly, as it only requires a tap to approve or deny login attempts. It also encourages app adoption.\nAttackers can use MFA fatigue attacks exploit push notifications by overwhelming users with repeated authentication prompts until they accidentally approve one.\nBackup security codes |\u0026mdash;\u0026mdash;\u0026mdash;-|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026ndash;|\nFactors - Something you have (a note with the codes) Security Low \u0026mdash;\u0026mdash;\u0026mdash;- \u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026ndash; Features - Possible offline backup \u0026mdash;\u0026mdash;\u0026mdash;- \u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026ndash; Backup Security Codes are single-use, one-time passcodes (OTPs) provided as a last-resort authentication method when other MFA options are unavailable. They should be displayed only once, never sent via email, and users should be allowed to regenerate them if needed. It’s best to notify users (via email or SMS) whenever a backup code is used. However, these codes should be avoided if alternative MFA methods are available, as users often do not store them securely.\nExternal Authentication External authentication delegates user verification to a trusted third-party service or identity provider (Idp).\nItsme Belgian eID |\u0026mdash;\u0026mdash;\u0026mdash;-|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;-| | Factors | - Something you have (eID card) |\n- Something you know (PIN) Security High \u0026mdash;\u0026mdash;\u0026mdash;- \u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;- Features - All Belgian citizens have one - Validate identiy information \u0026mdash;\u0026mdash;\u0026mdash;- \u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;- Authentication with Belgian eID cards is a secure method exclusively for Belgian citizens, using their national electronic identity card. It requires a card reader and the user’s PIN code, though many users forget or don’t know their PIN. Web authentication relies on mutual TLS (mTLS), ensuring encrypted communication between the card and the server. Organizations must maintain the PKI infrastructure, including government-issued CA certificates and support for evolving cryptographic schemes, to ensure compatibility and security.\nFederation with the company Idp |\u0026mdash;\u0026mdash;\u0026mdash;-|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;-|\nFactors - Depends on the Idp Security High \u0026mdash;\u0026mdash;\u0026mdash;- \u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;- Features - Very user friendly \u0026mdash;\u0026mdash;\u0026mdash;- \u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;- Federation with a client’s company Identity Provider (IdP), such as Microsoft Entra ID, allows users to authenticate directly through their organization’s system. This setup enables Single Sign-On (SSO), making it user-friendly by letting employees log in with their corporate credentials. Federation is typically based on the user’s email domain, automatically redirecting them to their company’s login portal. In OpenID Connect (OIDC), you can use the acr_values parameter to request specific authentication assurance levels. A direct link specific for the company should also be created so it can be shown on the company\u0026rsquo;s webportal.\nFederation with de facto standard and social Idp\u0026rsquo;s |\u0026mdash;\u0026mdash;\u0026mdash;-|\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;-|\nFactors - Depends on the Idp Security High \u0026mdash;\u0026mdash;\u0026mdash;- \u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;- Features - Very user friendly \u0026mdash;\u0026mdash;\u0026mdash;- \u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;\u0026mdash;- Federation with de facto standard and social IdPs (like GitHub, Google, Microsoft, Facebook, or LinkedIn) lets users log in to your service using their existing social or professional accounts.\nConsiderations when implementing MFA Temporarily trust a device for a set number of days to skip MFA prompts.\nTrusted Browsers: Use a secure cookie to maintain trust. Mobile Apps: Store an OIDC refresh token securely, avoiding indefinite reuse. Desktop Apps: Trust mechanisms vary by implementation. Registration If MFA is mandatory, provide a simple, step-by-step setup wizard to guide users through the configuration process.\nManaging MFA methods Enable users to manage their authentication methods through self service. They should be able to view their recent logins, including location, IP, and method used, as well as see when each authentication method was created and last used, for example, \u0026ldquo;Passkey (Windows): Created on 2025-10-13 00:11, last used on 2025-10-13 00:11.\u0026rdquo;\nAllow users to add, reset, or remove authentication methods, and ensure they can clearly see which account they are modifying by displaying their username, email, and other account information. Before permitting any changes, verify the user’s identity with a high level of assurance.\nSupport the creation of multiple authentication methods of the same type, such as several authenticator apps or passkeys, to provide flexibility and backup options.\nPassword reset Don\u0026rsquo;t forget to aks for a second factor after letting the user reset their password. This prevents malicious actors from gaining access to an account by doing a password reset.\nHelpdesk support Allow helpdesk to help a user get access to their account. But avoid social engineering attacks. Make sure that the user is thoroughly identified by the helpdesk.\nAudit logging Robust MFA audit logging is essential. Track when users add or use an authentication method, capturing key details like time, device, IP, location, and method type. This visibility helps detect anomalies, supports compliance, and enables quick incident response.\nConsider setup up authentication To improve user experience we don\u0026rsquo;t have to ask the user to authenticate with multiple factors during their initial login. We can provide limit access to the application with an easy to use method such as a simple password, magic link or trusted device. But only show less sensitive data and allow limited actions. If the user want\u0026rsquo;s to take sensitive actions, we can increase or \u0026lsquo;set up\u0026rsquo; our assurance level by requesting that the user authenticates using a second factor.\nIdeally the fine grained authorization policy engine can handle policies where a certain assurance level is required. In OIDC the amr and acr claims can be used to check te assurance level.\nRollout A phased rollout of multi-factor authentication (MFA) ensures a smoother, more effective implementation by allowing users to adapt gradually, reducing the risk of disruptions, and giving your IT and support teams the bandwidth to address issues as they arise. Starting with high-priority systems or user groups lets you focus resources where they’re needed most, while gathering feedback at each stage helps refine the process before wider adoption. This approach not only minimizes operational risks and user resistance but also ensures that security improvements are sustainable and aligned with both business needs and user experience. Ultimately, it’s about achieving strong security without compromising productivity or overwhelming your teams.\nPrepartion When preparing for an MFA rollout, it is important to:\nEnsure each user has only one account to avoid confusion or duplication. Verify that user contact details, such as phone numbers and email addresses, are accurate and up to date. Confirm that your Identity and Access Management (IAM) system fully supports the authentication methods you plan to implement.\nPhase 0: Enable MFA Phase 1: Focus group Learn lessons to improve user experience.\nPhase 2a: Recommend MFA for critical accounts Phase 2b: Enforce MFA for critical accounts Phase 3a: Recommend MFA for everyone ## Phase 3b: Enforce MFA for everyone Non-human account access delegation Allow services to access API\u0026rsquo;s on the users behalf using a dedicated API security mechanism, preferably [[OAuth]]. Often people want to use automations, the non-human service should not use the users credentials.\nSources https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html https://www.cyber.gc.ca/en/guidance/steps-effectively-deploying-multi-factor-authentication-mfa-itsap00105\n","permalink":"https://notes.robinvanhove.me/notes/mfa/","summary":"\u003ch1 id=\"what-is-mfa\"\u003eWhat is MFA\u003c/h1\u003e\n\u003cp\u003eMulti-factor authentication (MFA) is a security process that requires users to\nverify their identity using two or more distinct factors. Each factor can be\nfrom one of the following categories:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eSomething you know (e.g., a password)\u003c/li\u003e\n\u003cli\u003eSomething you have (e.g., a security token or mobile device)\u003c/li\u003e\n\u003cli\u003eSomething you are (e.g., a biometric such as fingerprint or face recognition)\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eFor an authentication method to be secure, it should validate at least two\nfactors.\u003c/p\u003e","title":"Multi Factor Authentication"},{"content":"Principles Let\u0026rsquo;s first describe some principles that should in order of importance.\n1. Pragmatic Security When creating an API the primary goal is to solve a problem for a user or organisation. But we don\u0026rsquo;t want to create new problems by introducing vulnerabilities.\nWhen designing or implementing a new feature always consider how it could be abused and strive for security by design.\nBe pragmatic, solve problems don\u0026rsquo;t create new ones.\n2. Use Standards \u0026amp; Frameworks When it comes to security, many organisations face the same problems, luckily as a result we can also use the same solutions. In the world of software engineering we are blessed with great open standards organisations and communities such as OWASP, IETF, the OpenID Foundation, and the many open source communities.\nWhen faced with a check if one of the tools you are using might already have a solution or look online if there are no current best practices on how it can be solved.\nFor example, the front-end framework you are using probably has a way to obtain OAuth tokens, and don\u0026rsquo;t implement JWT validation yourself, your API framework or standard library probably has an implementation of JOSE already.\nBut be ware of the third-party risk, don\u0026rsquo;t just add any random library as a dependency.\nUsing standards and frameworks ensures interoperability, not only internally but also when working with vendors, partners and customers. It also ensures that we use reviewed solutions and implementations.\n3. Layered Security ZTA \u0026hellip; Guidelines Threat Model The first step when considering security for any project is to start with a threat model. Don\u0026rsquo;t know what threat modeling is? Take a look at the Threat Modeling Manifesto which gives the following definition.\nThreat modeling is analyzing representations of a system to highlight concerns about security and privacy characteristics.\nThe manifesto describes four questions to ask to start threat modeling.\nWhat are we working on? (Create a model) What can go wrong? (Identify threats) What are we going to do about it? (Design \u0026amp; implement mitigations) Did we do a good enough job? (Review \u0026amp; repeat) Plenty has been written online about threat modeling, so there is no need to explain it further in this note. But I would like to highlight the following.\nThreat modeling as a team activity, not a CISO requirement Threat modeling should be an activity practiced by the team designing and implementing the system. It\u0026rsquo;s a fundamental way of doing pragmatic security by focussing on mitigating the threats that really matter.\nCreating and discussing the potential threats your system faces is a great way to get the team to think about security and have security by design.\nUnfortunately a threat model is often seen as a requirement form the CISO-office which might require a DFD-diagram and threat categorized with STRIDE so they can check the checkbox on their compliance spreadsheet without really caring about security. Threat modeling without involving the team is a waste of time.\nModel your way Data-flow-diagrams DFD\u0026rsquo;s and STRIDE can be great tools, but if you already have other models of your system you should not have to create a new digram form scratch.\nContinuous Threat Modeling When adding a new endpoint or making changes to an existing one, make sure to update your threat model. Threat modeling is a continuous activity and not a one off.\nFurther reading Threat Modeling - OWASP Cheat Sheet Series Threat Modeling Manifesto Pentest Internet facing API\u0026rsquo;s should always be pentested.\nMonitoring \u0026amp; Logging Ideally a security operations center (SOC)\nSecure your transport layer!\nTLS 1.2+ Check certificates DNSSEC Secure ciphers https://ciphersuite.info HTSTS References OWASP API Security Top 10 [1]: OWASP Application Security Verification Standard (ASVS) | OWASP Foundation REST Security - OWASP Cheat Sheet Series Threat Modeling - OWASP Cheat Sheet Series ","permalink":"https://notes.robinvanhove.me/notes/security/","summary":"\u003ch2 id=\"principles\"\u003ePrinciples\u003c/h2\u003e\n\u003cp\u003eLet\u0026rsquo;s first describe some principles that should in order of importance.\u003c/p\u003e\n\u003ch3 id=\"1-pragmatic-security\"\u003e1. Pragmatic Security\u003c/h3\u003e\n\u003cp\u003eWhen creating an API the primary goal is to solve a problem for a user or\norganisation. But we don\u0026rsquo;t want to create new problems by introducing vulnerabilities.\u003c/p\u003e\n\u003cp\u003eWhen designing or implementing a new feature always consider how it could be abused and\nstrive for security by design.\u003c/p\u003e\n\u003cp\u003eBe pragmatic, solve problems don\u0026rsquo;t create new ones.\u003c/p\u003e","title":"My Security Prinicples \u0026 Guidelines"},{"content":"","permalink":"https://notes.robinvanhove.me/notes/openid_ssf/","summary":"","title":"OpenID Shared Signals Framework"},{"content":"In the classic XCAML based fine grained authorization ([[fga]]) architecture, the Policy Decision Point or PDP is responsible for deciding weather a subject such as a user is allowed to do an action on a specific resource.\nBut in many real world architecture this pattern is difficult to apply. Let\u0026rsquo;s look the following simple example. We want to built an application that shows a simple list of all documents a user has access to.\nWe could retrieve all documents from the datastore and ask the PDP whether our user has access and only return those. But that has an obvious disadvantage.\nThe people over at OpenID AuthZen have proposed to a search API. Where instead of searching in our datastore, we search in the PDP directly. Unfortunately this approach makes it difficult or at least impractical to implement filters by the applications such as search by document name.\nIn this case the PDP would also be responsible for pagination which may not be preferred. Additionally the PDP would have to know about each resource and their relevant attributes. In reality this is something stored in the datastore.\nWhat we really need in practice are policy-based data filters. Where we ask the PDP for a filter under which condition the user is allowed to access a resource. We can then combine this authorization filter with any filer need by the application logic to query the datastore.\nExample worked out in [[opa_data_filter]]\nAuthZen Data Filter API draft https://hackmd.io/@oidf-wg-authzen/HkLiZVdb1l\n","permalink":"https://notes.robinvanhove.me/notes/pbac_data_filter/","summary":"\u003cp\u003eIn the classic XCAML based fine grained authorization ([[fga]]) architecture,\nthe \u003cem\u003ePolicy Decision Point\u003c/em\u003e or PDP is responsible for deciding weather a subject\nsuch as a user is allowed to do an action on a specific resource.\u003c/p\u003e\n\u003cp\u003eBut in many real world architecture this pattern is difficult to apply. Let\u0026rsquo;s\nlook the following simple example. We want to built an application that shows a\nsimple list of all documents a user has access to.\u003c/p\u003e","title":"Policy-Based Access control with data filters"},{"content":"FOSDEM 2026 Main track Free as in Burned Out: Who Really Pays for Open Source? FOSS in times of war, scarcity and (adversarial) AI DEFCON 33 All your keyboards are belong to us! Cosic PQCSA Workshop Brussels 2026 https://www.youtube.com/watch?v=fLcyN2SM1Tk\nNDC Copenhagen 2025 (Azure) Modern Architecture 101 for New Engineers \u0026amp; Forgetful Experts - Jerry Nixon - NDC Copenhagen 2025 ","permalink":"https://notes.robinvanhove.me/notes/talks/","summary":"\u003ch2 id=\"fosdem-2026\"\u003eFOSDEM 2026\u003c/h2\u003e\n\u003ch3 id=\"main-track\"\u003eMain track\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cinput disabled=\"\" type=\"checkbox\"\u003e \u003ca href=\"https://fosdem.org/2026/schedule/event/L3BK7S-free-as-in-burned-out/\"\u003eFree as in Burned Out: Who Really Pays for Open Source?\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003cinput checked=\"\" disabled=\"\" type=\"checkbox\"\u003e \u003ca href=\"https://fosdem.org/2026/schedule/event/FE7ULY-foss-in-times-of-war-scarcity-and-ai/\"\u003eFOSS in times of war, scarcity and (adversarial) AI\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"defcon-33\"\u003eDEFCON 33\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cinput disabled=\"\" type=\"checkbox\"\u003e \u003ca href=\"https://www.youtube.com/watch?v=KeNBWILSlC4\"\u003eAll your keyboards are belong to us!\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"cosic-pqcsa-workshop-brussels-2026\"\u003eCosic PQCSA Workshop Brussels 2026\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://www.youtube.com/watch?v=fLcyN2SM1Tk\"\u003ehttps://www.youtube.com/watch?v=fLcyN2SM1Tk\u003c/a\u003e\u003c/p\u003e\n\u003ch2 id=\"ndc-copenhagen-2025\"\u003eNDC Copenhagen 2025\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cinput disabled=\"\" type=\"checkbox\"\u003e \u003ca href=\"https://www.youtube.com/watch?v=WRg13Ze_UpY\"\u003e(Azure) Modern Architecture 101 for New Engineers \u0026amp; Forgetful Experts - Jerry Nixon - NDC Copenhagen 2025\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e","title":"Talks to watch later"}]