- Cloud access security broker (CASB)
- Security Assertion Markup Language (SAML)
- OAuth
- OpenID
- OpenID Connect (OIDC)
- System for Cross-domain Identity Management (SCIM)
Cloud access security broker (CASB)
- access control to SaaS
- end user behaviour analytics (UEBA)
- detect access location movement for more than reasonably expected
- DLP by searching documents using regexp
- inline CASB
- reverse proxy: before resource, resource protection
- forward proxy: before user, user protection
- out-of-band CASB:
- API-based
- log-based
- protects from phishing attacks, abusing OAuth protocol
Cloudlock
- API-based CASB
- Okta as identity management service (IMS)
Security Assertion Markup Language (SAML)
- authC + authZ, SSO across security domains
- XML, SOAP
- entities
- principal: user
- SAML authority: identity provider
- relying party: service provider
- assertion
- created by IdP
- attributes, access privileges per object
- SP assertion service creates context and redirects to resource
- bindings
- SP and IdP can use binding independently from each other (e.g., SP – Redirect and IdP – POST)
- parameters
- RelayState: exchange ID
- SAMLRequest
- SAMLResponse
- types
- HTTP Redirect
- deflate + Base64 encoding
- SAML parameters are sent as URL parameters
- limited by URL max length
- limited by web browser GET buffers
- HTTP POST
- Base64 encoding
- reply to user agent with XHTML forms, containing parameters
- form submission is automated using JS:
window.onload = function () { document.forms[0].submit(); }
- artifacts
- only references are passed via user agent: SAMLArtifact parameter in URL
- SAML assertions are exchanged between SP and IdP directly
- HTTP Redirect
- deployment
- SP-initiated
- service refers to IdP on initial request
- IdP-initiated
- IdP posts SAML response to SP assertion service in advance
- SP-initiated
- messages
- SAML request
- can be signed
- SAML response
- limit – 4 MB
- can be signed
- SAML request
OAuth
- token-based authZ, no username/password exchange
- resource provider (e.g., Google) authorizes resource owner (e.g., user) to allow 3rd party the access to data
- requires authentication
- flows:
- 2-ledged API: API, client cledentials
- 3-ledged API: user interactive
- grant
- authZ code: short-lived code to receive token using browser
- client credentials: access to device without user interaction (e.g., API)
- device code: receive code and exchange it for token without browser (e.g., smart TV)
- refresh token
- password: legacy, exchange password for token
OpenID
- authC framework
- ≈ SAML with 3rd party IdP (AWS, Google, Facebook, …)
OpenID Connect (OIDC)
- authC + OAuth 2.0
- used for authC and to get additional information from IdP
- authZ code flow
- client receives user info directly from IdP
- can authenticate client
- server backend is required for an app
- implicit flow
- browser-based application without backend (e.g., JavaScript)
- token passes through browser ⇒ vulnerable to MITM
System for Cross-domain Identity Management (SCIM)
- push user information: after authC
- JSON, REST
- triggers and actions: CRUD
- create user
- update user
- delete user