Verzamelbak

[0xgeert]

Product Vectors

• ala Jarnain, etc
• ala onelogin, etc.

Order of things

1. scim
   • user creation
     • temp save to ldap implementation?
   • group creation
   • tenant creation
2. authentication using oAuth2 for Scim endpoints
   • using bearer tokens
3. oauth 2 for authorization (without 3rd party apps)
   • usable from here! with clients doing hasRole
   • but only for authroization app itself
   • Tenant Role
   • authorization app (resource) should ask authorization server to validate token, etc.
4. Introduction of App ResourceType (app = client)
   • including Application Owner Role
5. Simple provisioning
   • implementing birthright provisioning
   • Role-based (only from groups made in cloud not yet from directory)
   • NO approval workflows yet
   • Rule-based (already?). Although, this will blur the line with Role-based, since Rule-based are just dynamic segments where Role-based are Static segments . Where segments (eager read derivation) are used as the basis of auto-provisioning. (ES: voldoen aan query / niet meer voldoen aan query (?) is picked up automatically) which can be used as trigger for all this
6. Permissions Loads of stuff can be done without this, but useful. think about defining only spefific types of permissions, i.e: API permissions, which is the most straightforward usecase
   • introducing Permission ResourceType:
   • being able to define permissions and how to link them to Groups
   • whole permission resourceType storage etc.
7. Identity Provider - Directory-as-a-service
   • allows way to save users in cloud
8. Directory sync and unified whole?
   • multiple directories
   • user merge?
9. Authentication extras
   • openID Connect
   • multi-factor
   • flows (also more forms)
   • all kinds of strong authentication
10. SSO / Federation
    • Single Sign in (ala onelogin.com)
11. Enterprise Provisioning
    • approval workflows
    • request based stuff
    • killswitch / deprovisioing
    • auto-creation of 3rd party app-accounts (and reusing them on move/leave)
    • auto-triggers of provisioning
      • birth / move / leave / manual audit / recertification / auto anomaly detect

Tangently related

• Sessions-as-service
• Canned Forms for authentication
  • Clientside - (CORS + IFrame)

[0xgeert]

Authentication

The act of proof delivered by a user that he is who he says he is.

Credential Types

• what you know (e.g.: password)
• what you are (e.g.: fingerprint)
• what you have (e.g.: hardware token)

Functionality

• Auth Workflows
  • sign up (**TODO: there's a name for signing up by user himself, instead of getting added to directory or something)
  • login
  • reset
• multi-factor (it's only multi-factor if authentication based on at least 2 different credential types as defined above)
• apps may have certain trust-levels and means of authentication may have certain trust-levels. i.e:
  • BYOI auth (facebook, etc.) is low trust
  • "remember me" cookie is low trust
  • username/pass is high trust
  • strong authentication is ultra high trust, etc.
• BYOI - Bring-your-own-identity. TODO: is this really what is meant with BYOI
  • facebook / twitter/ linkedin / github identity to be used / coupled to identity, but can only be used for 'weak authentication'
  • other way around: logging in with strong auth also gives byoi? probably not, since this should NOT be controllable by IT but is private to Resource Owner
• strong auth
  • multi-factor (mobile app, phi certificates, RSA, symantec, vasco, yubico)
  • policies
  • password strength/length
  • required character-groups,
  • password rotation / expiration,
  • allowed retries, falloff-type/ envelope for retries,
  • kickoff flow in case of too many retries, etc.
  • desktop SSO
  • VPN
  • RADIUS interface (one time pass, wifi hotspot, ipsec vpn)
  • any combi of auth possible (configurable flows, also for reset and account create flows)

    Relevant Standards

• openid Connect (build on oauth2)
  • Basic client Profile
  • other profiles
  • Todo: _what's that PROFILE I keep hearing about? _
• oauth2 tokens
  • bearer tokens (default) don't carry authentication proof (everybody who has the token may impersonate as user)
  • MAC tokens: signed tokens between trusted client (?) and authorization server
  • SAML tokens in combi with oauth2
  • JWT tokens
• SAML (token carries authentication)

oAuth2 for Authentication

OpenID Connect

Authorization

when authenticated to act of granting certain (access)rights to a user.

oauth2

oauth 2 endpoints

• /authorize
• /token (different grant types)
• /validate (token indeed valid)
• /tokeninfo (expiration, scope, exists)
• /redirectUrls (registering of redirecturls)

grant types

Authorization Code Grant

Implicit Grant

Resource Owner Password Credentials Grant

Client Credentials Grant

usecases (+ grant mapping)

UMA

Group, & Role management

1. directory group to canonical group mapping
   • option 1: 1-on-1
   • option 2: rule-based
2. own group creation (hierarchic) as well as Role
   • manual assignment
   • rule-based assignment

Both methods 1. and 2. can be combined.

Identity Management

Functionality

Identity Provider / Directory Syncing

Syncing to multiple Identity providers, such as:

• LDAP instances
• Active Directory (AD) instances
• workday instances

Which ensures a total view of all identity providers together.

Functionality

• killswith for user
• 2-way?
  • update flow from directory (behind firewall) --> aggregated store (normal I guess)
  • update from aggregated store --> directory (this would be used for killswitch for example)

Provisioning

Way in how Users are assigned rights (aka: permissions, grants, entitlements)

Commonly:

• access to app
• access to particular elevated features in app

Types

• birthright provisioning
• rule-based provisioning (often based on declarative rules defined as a combination of attribute values)
• role-based (often simpler than rule-based, and can be used when in-line with say divisions in corporation)
• request-based (a user may request specific access which it may be granted)
• deprovisioning (demotion, fire, leave, sabbatical,etc)

attributes to base provisioning on (besides the request based stuff)

• combi of user attribs
  • group (ldap / ad / workday)
  • role
  • division
  • age

Functionality

• customizable (declarative) workflows, which may include human actors for "boss approval"-workflows
• workflows may be derived from best practice templates
  • store with such templates (per industry possible even)
• workflow triggers
  • birth/joiners
  • movers
  • leavers
  • recertification
  • request based
  • manual audit
  • based on automatic detection (roque agent hammering or other anomolies)
  • may be realtime
  • and/or audit-log based
• federated account (3rd party) creation and access grant. e.g: auto-creating an account with zendesk
  • SAML (so no password creation needed)
  • otherwise Password Management / vaulting.
• reuse of 3rd party account when user deprovisioned.
• grant access rights (right to login to app)
  • on premise (enterprise owned or 3rd party)
  • in cloud (enterprise owned or 3rd party)
• grant elevated rights in app, (often called "entitlements" in federation/3rd-party context)

SSO / Federation

• Signin to multiple apps automatically
• Sign in to 3rd party apps as well
• Federation also relates to 3rd party app provisioning
• launch by click within overview app
• app (also on Ipad) enables to launch apps beyond firewall?! (onelogin.com)
• SSO app for multiple devices
• private apps - i.e: not controlled by IT. User must fill-in own passwords presumably
• apps can be provisioned by IT - i.e: accounts are created automatically without enduser ever knowing the password.
• accounts can be reused in case of leavers
• side-stepping SSO is tracked - i.e. : when (attempted) logins are made to 3rd party apps outside of controlled SSO environment
• possible to integrate with loads of apps
• enterprise apps (either in cloud or on premise) can be integrated easily as well
• coupled to windows network login
• including correct deeplinking inside app with correct SSO-login (onelogin.com)
• multiple instances of some app per user possible
• shared instances between users possible (if 3rd party app provides this functionality) i.e: single app -> multi user.
  • for instance: shared corporate twitter account

Federated Search

• onelogin.com provides this
• this needs to be integrated on per-app basis
• needs to take per-user permissions into account for each app

SCIM: standard

Permissions

Given a custom app authorization can be done based on user.hasRole(roleX) etc. A better more fine-grained way would be to expose a set of permisions, (aka entitlements, grants) and do user.isAuthorized('entitlementA').

advantages of explicit permissions (aka: resource based access control)

• entitlements can be designed on a level that makes sense to the app / app-designer. Most of the time, Role-design and permission-design are not controlled by the same people, leading to possible permission-creep, etc.
• Instead, using explicit permissions it's possible to explicitly code permissions into the app, and do a permissions -> User mapping outside of the app. This ensures:
  • the app source-code doesn't have to change based on changed roles / groups, etc.
  • new Roles can just be added and given permission when needed.
  • fine-grained control on a per-user basis is possible, etc.
  • responsibility of who has access / entitlements to what stays exclusive to the IDM - server, instead of creeping into individual apps.

Stormpath blog: http://www.stormpath.com/blog/new-rbac-resource-based-access-control mentioning:

• Reduced Code Refactoring
• Resources and Actions are intuitive
• Flexible Security Model
• Externalized Security Policy Management
• Make Changes at Runtime

Monitoring / Audit

• audittrail
  • failed attempts
  • app logsins
  • user updates
  • etc.