Cedar and Google Zanzibar are both systems designed to manage access control within software applications or systems, but they may have different architectures, features, and capabilities.
Architecture:
Cedar Authorization: The architecture of Cedar authorization would depend on the specific implementation and design choices made by its developers. Depending on the application’s requirements, it could be a centralized or decentralized system.
Google Zanzibar: Zanzibar is a centralized system for managing access control in distributed systems, developed by Google. It uses a global namespace and relies on a centralized policy decision point for access control decisions.
Scalability:
Cedar Authorization: Scalability would depend on the scalability features and design decisions implemented within Cedar. It may be scalable depending on its architecture.
Google Zanzibar: Zanzibar is designed for scalability and manages access control at Google’s scale, handling millions of authorization requests per second.
Features and Capabilities:
Cedar Authorization: Features and capabilities would depend on the specific implementation of Cedar. It may offer features such as role-based access control (RBAC), attribute-based access control (ABAC), and fine-grained access control policies.
Google Zanzibar: Zanzibar provides features for managing authentication, authorization, and auditing in large-scale distributed systems. It offers a global namespace for managing access control policies, supports complex access control rules, and provides auditing capabilities.
Usage and Adoption:
Cedar Authorization: The usage and adoption of Cedar would depend on factors such as its availability, ease of integration, and suitability for different types of applications.
Google Zanzibar: Zanzibar is used internally by Google to manage access control across its various services and applications.
In summary, while both Cedar authorization and Google Zanzibar are systems for managing access control, they may differ in their architecture, scalability, features, and usage. The specific differences would depend on the details of each system’s implementation.
Cross-Domain Single Sign-On (CD-SSO) is a solution which lets users authenticate at one application domain and then use that same user session at many completely different application domains without re-authenticating over and over again.
Where in regular SSO, the user Session Cookie is bound and valid within same application domain i.e., sso.example.com, host1.example.com & host2.example.com has same application domain example.com on all servers.
Where in CD-SSO, the user Session Cookie is bound and valid across different application domains i.e., sso.example.com, host1.example1.com & host2.example2.com has different application domains (example.com, example1.com and example2.com) on all servers and hence Session Cookie are not shareable between servers.
Since in the cross-domain scenario the Session Cookie isn’t accessible, the concept of CD-SSO helps to achieve the single sign-on across different domains.
To realize CD-SSO, a mechanism called Federation is being used and there are some open standard federation protocols define how the two parties (Service Provider and Identity Provider) build a trust and communicate to authenticate the user’s identity.
Standards are critical as they allow inter-operability between different organizations and vendors – enabling connections to be made to many partners and applications easily and securely.
In federation terms, the two parties are typically called as
Identity Provider (IdP): A provider that creates, maintains, and manages identity information for users and provides user authentication to other service providers within a federation.
Service Provider (SP): A provider that relies on IdP for user authentication and provides services only to the authenticated users.
A Federation is “An association comprising any number of service providers and identity providers.”
There are three open standard federation protocols used widely today:
Federation Protocols
Explanations
Used For or Used In
Security Assertion Markup Language (SAML)
– XML-based markup language used to exchange authentication and authorization data between an IdP and SPs.
– The authentication and authorization data is called as Security Assertions or Tokens (statements that SP use to make access-control decisions).
There are three versions of Assertions called SAML 1.0, 1.1 and 2.0 with version 2.0 being the most common implementation of SAML available.
WS-Federation (WS-Fed)
XML-based protocol describes the management and brokering of trust relationships and security token exchange across web services and organizational boundaries and part of WS-* family of protocols.
Widely used in Microsoft and IBM environments.
OpenID Connect
Designed as an extension to the popular OAuth 2.0 protocol used in web service security. OpenID Connect adds an authentication and identity layer on top of the core OAuth 2.0 protocol allowing an application to authenticate a user and receive a token it can use for API calls via the same process.
Optimal for internal SSO, web application SSO and mobile SSO.
To simplify the concept, let’s use SAML2.0 as a federation protocol and SAML2.0 Assertion as a security token to explain about CD-SSO flow.
Cross-Domain SSO (Federation) Sequence Diagram using SAML2.0 Protocol and Assertion
Note: All servers are hosted on different domains (i.e., at example.com, example1.com & example2.com).
User request page1.html from host1.example1.com (Application-1 & Federation SP-1).
host1.example1.com sees there is no valid Session Cookie.
Hence redirect the user to sso.example.com (Federation IdP) for authentication with return URL as page1.html.
Browser request for authentication (i.e., SAML AuthN Request) at Federation IdP.
Federation IdP displays login page for the user to enter their username/ password.
User submits username/ password.
Federation IdP,
Authenticates the submitted credentials.
Generates SAML2.0 Assertion for the requester host1.example1.com.
Federation IdP,
Sends the SAML2.0 Assertion (in SAML AuthN Response) to the requester endpoint (i.e., the endpoint to consume the token which is already known to IdP via Circle of Trust Establishment process; see below), along with redirect URL as page1.html (from #3).
Sets IdP Session Cookie with the following attributes.
Cookie Attributes
Values
Explanations
Name/ Value
SessionID=SP1_123
This Session Cookie is named as SessionID and value as SP1_123 (i.e., SP1 is requester and 123 is associated userid).
Domain
example.com
This Session Cookie is valid for domain example.com only.
Path
/
This Session Cookie applies to path root.
Expires/ Max-Age
2018-08-24T22:30:17.000Z
This Session Cookie will expire on July 24, 2018 at 10:30PM, GMT.
HttpOnly
HttpOnly
This Session Cookie is not accessible from JavaScripts.
Secure
Secure
This Session Cookie can be sent only in HTTPS connections.
SameSite
Strict
This Session Cookie is not valid for any cross-domain browsing context.
Browser post the SAML2.0 Assertion to requester endpoint.
Application-1 & Federation SP-1 validate the received SAML2.0 Assertion.
Application-1 & Federation SP-1,
Sets its own Session Cookie with the domain example1.com.
Finally allows user to access page1.html.
After sometime, in the same browser session, the same user tries to access page2.html at host2.example2.com (Application-2 & Federation SP-2).
host2.example2.com sees there is no valid Session Cookie.
Hence redirect the user to Federation IdP for authentication with return URL as page2.html with SAML AuthN Request.
Browser request for authentication (i.e., SAML AuthN Request) at Federation IdP; but this time a valid IdP Session Cookie is also sent, because browser sends cookie to the domain (example.com) where the cookie was set from #8.2.
Federation IdP,
ValidateS the received IdP Session Cookie that it set at #8.2, which is bound and valid to domain example.com.
Hence IdP did not challenge the user for login one more time and thus generates the SAML2.0 Assertion for the requester host2.example2.com.
Federation IdP,
Sends the SAML2.0 Assertion (in SAML AuthN Response) to the requester endpoint, along with redirect URL as page2.html (from #14).
UpdateS the IdP Session Cookie to have SessionID=SP1_SP2_123 (i.e., SP1_SP2 are requesters and 123 is associated userid).
Browser post the SAML2.0 Assertion to requester endpoint.
Application-2 & Federation SP-2 validate the received SAML2.0 Assertion.
Application-2 & Federation SP-2,
Sets its own Session Cookie with the domain example2.com.
Finally allows user to access page2.html.
Note: Session Cookie Value field is encrypted, which contains the information about the user (123) and requesters (SP1 and SP2) and sent by the servers to the web-browser. The value shown for readability purpose only.
Circle of Trust Establishment
For a Service Provider (SP) to trust an assertion generated and sent by an Identity Provider (IdP), a trust mechanism must be established.
This federation trust mechanism is the foremost step before setting-up the SSO between SPs’ and IdP.
Generally trust is achieved by exchanging a metadata file, which contains information elements about the connection and digital signature certificate of each party.
On exchanging the metadata files between IdP and SPs’, a trust relationship between these parties are established.
This concept shall be discussed in detail when we look SAML protocol.
Single Sign-On (SSO) is a solution which lets users authenticate at one application and then use that same user session at many completely different applications without re-authenticating over and over again.
HTTP Cookies (RFC 6265) are vital component to achieve SSO, as it tracks the user’s session across different applications. Before going in detail on SSO, let’s look at the HTTP Cookies.
HTTP Cookies
An HTTP cookie is a name-value pair data sent by a web-server (party-1) to a web-browser (party-2) to maintain a state between those two parties.
Because of state maintenance mechanism, cookies are used for,
Tracking user’s information and browsing patterns: For example: preserving cart items in a shopping website and displaying advertisements based on browsing history .
User authentication: To know whether the user is logged in or not, and which account they are logged in with.
HTTP Cookies (RFC 6265) has defined some attributes associated with cookies: They are:
Attributes
Explanations
Name/ Value
Any US-ASCII characters with some exceptions.
For example: SessionID=123
Domain
– If specified, the domain and subdomains of the cookie where this cookie can be sent to. For eg: if Domain=example.com; then browser can send cookie to example.com and host1.example.com as well)
– If not specified, domain will be derived from the request-domain (actual hostname from URL) and browser only send to the exact domain and not to its subdomains. For eg: from earlier case, the browser can send only to host that which it set the cookie, i.e., to host1.example.com only.
Path
A given URL path where the cookie applies to. For eg: / (i.e., root path)
Expires
GMT timestamp that says when the cookie expire.
For eg: 2018-08-24T22:30:17.000Z. If not specified, the cookie is valid until the browser closed.
Max-Age
The amount of time (in seconds) the cookie should be valid. For eg: 3600. Both Expires and Max-Age are used for session timeout and context remains same. If both (Expires and Max-Age) are set, Max-Age will have precedence.
Secure
When used, the cookie can be only transferred through HTTPS, regular HTTP requests won’t include this cookie.
HttpOnly
When used, the cookies aren’t accessible via JavaScript, giving some protection against cross-site scripting (XSS) attacks.
SameSite
Prevents the browser from sending the cookie along with cross-site requests. Provides some protection against cross-site request forgery (CSRF) attacks. Possible values are:
– Strict: Cookie won’t be sent to target site in all cross-domain browsing context.
– Lax: Cookie will be sent along with the GET request initiated by the third-party website, but not request to POST or request originated from iframe, img, and script tags.
CSRF attacks are only possible since Cookies are always sent with any requests that are sent to a particular origin, which is related to that Cookie. Due to the nature of a CSRF attack, a flag can be set against a Cookie, tuning it into a same-site Cookie. A same-site Cookie is a Cookie which can only be sent, if the request is being made from the same origin that is related to the Cookie being sent. The Cookie and the page from where the request is being made, are considered to have the same origin if the protocol, port (if applicable) and host is the same for both.
Creating a cookie with same name (value can be anything), and set the Expires property to a date in the past will make that cookie to be removed or cleared-out from the browser and user will lose his/ her session.
How Cookies are related to SSO?
Cookies are the ones controls and tracks the user session in the web-browser and that helps to achieve the SSO across all applications within the same domain. Refer below sequence diagram and its explanations in detail.
SSO Sequence Diagram
Note: All servers are hosted in the same domain example.com.
User request page1.html from host1.example.com (Application-1 & Web Agent-1).
host1.example.com sees there is no valid Session Cookie.
Hence redirect the user to sso.example.com (SSO & Authentication Services) for authentication with return URL as page1.html.
Browser request for authentication to Authentication service.
Authentication service displays login page for the user to enter their username/ password.
User submits username/ password.
Authentication service authenticates the submitted credentials.
Upon successful authentication, Authentication service sets redirect URL to page1.html (from #3) and SSO service sets the Session Cookie with the following attributes:
Cookie Attributes
Values
Explanations
Name/ Value
SessionID=123
This Session Cookie is named as SessionID and value as 123.
Domain
example.com
This Session Cookie is valid for domain example.com and all its subdomains like sso.example.com, host1.example.com and host2.example.com.
Path
/
This Session Cookie applies to path root.
Expires/ Max-Age
2018-08-24T22:30:17.000Z
This Session Cookie will expire on July 24, 2018 at 10:30PM, GMT.
HttpOnly
HttpOnly
This Session Cookie is not accessible from JavaScripts.
Secure
Secure
This Session Cookie can be sent only in HTTPS connections.
SameSite
Strict
This Session Cookie is not valid for any cross-domain browsing context.
Browser redirect to page1.html at host1.example.com with the Session Cookie.
host1.example.com asks SSO service to validate the received Session Cookie.
SSO service validates and return response to host1.example.com.
Finally host1.example.com allows user to access page1.html.
After sometime, in the same browser session, the same user with valid Session Cookie request to access page2.html at host2.example.com (Application-2 & Web Agent-2).
host2.example.com request SSO service to validate the received Session Cookie.
SSO service validates and return response to host2.example.com.
Finally host2.example.com allows user to access page2.html without asking to re-login at sso.example.com.
This is because the Session Cookie is bound and valid to domain example.com, and hence SSO & Authentication Services did not authenticate the user once again.
Conclusion
So far we saw SSO works fine across applications when their domain name is same (i.e., sso.example.com, host1.example.com and host2.example.com, all are based on same domain example.com).
But what happen if applications running on different domains? For example: sso.example.com, host1.example1.com, host2.example2.com. How to achieve SSO for these applications?
The answer is Cross Domain-Single Sign-On (CD-SSO).
Let’s discuss about CD-SSO in next blog post. At least this blog gives some basic concepts on SSO and let’s look in the next post for complex use-cases on CD-SSO.
Before going into the Lightweight Directory Access Protocol (LDAP), we have to look into what are Directory Services and X500 Model.
Directory Service
Directory Service is a concept that characterized as a hierarchical tree-based naming system that offers numerous distributed system advantages:
Unique names can be determined by concatenating hierarchical naming components starting at a root node (e.g., “com”).
Object-oriented schema and data model supports very fast search operations (uses Key-based querying).
Due named sub-tree partitions, the features like Distribution, Replication and Delegated or Autonomous Administration are supported.
Supports Authentication and Fine-Grained Access Control mechanisms.
Few examples of directories are DNS, NOS, Novell’s NDS, Microsoft’s Active Directory.
Directories are designed and optimized for more READ/ SEARCH operations, than WRITE/ UPDATE operations.
In real world example, a telephone directory is a directory system that contains a list of subscribers with an address and a phone number in a dictionary format, than in a tree-based fashion.
Telephone Directory
X500 Model
X.500 is a series of computer networking naming standards and models for Directory Service.
The primary concept of X.500 is that there is a single Directory Information Tree (DIT), a hierarchical organization of Entries and these can be called using:
Distinguished Name (DN) is a unique Distinguished Name. Much like a “path” to a filename in a file system.
For eg: cn=alice, ou=People, dc=example.com
Relative Distinguished Name (RDN) is a component of the distinguished name. Much like a “filename” in a file system.
For eg: cn=alice, ou=People is a RDN relative to the root RDN dc=example.com
Directory Information Tree (DIT)
DNs are also called as naming contexts, because it describes the namespace where the entry lives.
X500 Model suggest the way how directory service can be designed in a DIT to have a database to fetch information for a given entry.
Directory Access Protocol (DAP) is one of the protocol defined in X.500 that says how to access the entries in the DIT on TCP/IP stack.
LDAP
The Lightweight Directory Access Protocol (LDAP) is an open, vendor-neutral, industry standard Application Layer protocol interface for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network.
The latest specification is Version 3, published as RFC 4511.
LDAP is based on:
A simpler subset of standards within X.500 model, hence sometimes LDAP is called as X.500-lite.
DAP to access X500 model directory, hence it is called as Lightweight DAP.
Naming Model
An Attribute defines as a piece of information that the directory entries contain.
Attribute is similar to DB column name.
The most widely used naming attributes are defined in the following table:
Attr.
Abbreviations
Explanations
Examples
dc
domainComponent
An element of a DNS domain name
dc=acme,dc=com
uid
userid
A person’s account name
uid=jdoe
cn
commonName
Full name of a person, group, device, etc.
cn=John Doe
l
localityName
Name of a geographic region
l=Bay Area
st
stateOrProvinceName
State or Province
st=CA
o
organizationName
Organization name
o=Acme
ou
organizationalUnitName
Organization unit name
ou=Sales
c
countryName
Two letter country code
c=US
Schema Model
An LDAP schema is a set of rules that define what can be stored as entries in a LDAP directory.
We have similar concept in RDBMS, where DB schema contains information about database structure, tables, columns, data types and constraints.
The schema model consists of two types of elements:
1. Object Classes:
Defines as a placeholder for attributes.
Similar to DB tables.
Object classes come in one of three kinds:
Abstract
Structural
Auxiliary
Defines an attribute or set of attributes that all object classes in an object class structure inherit.
Every object class structure must have an abstract object class as the top-level object class.
Defines an object entry type.
Every entry must contain at least one structural object class.
A structural object class inherits either from top or from another structural object class.
An auxiliary object class adds attributes to another object class.
Useful to define a set of attributes used by multiple object classes.
There are only two abstract classes:
The top class is present in every entry, and it requires the objectClass attribute be present.
The alias requires the aliasedObjectName attribute be present.
For example: Object classes such as organization, person, organizationalPerson or device.
For example: Object class strongAuthenticationUser allows the attribute userCertificate;binary be present, but this class could be used in an entry with object class person, device or some other structural class.
Object Classes in a Class Diagram
2. Attribute Types:
Defines the data types of attribute values.
Similar to DB column’s data types.
Attribute Type Definition specifies:
Syntax
Matching Rules
Defines the data format in which an attribute value is stored.
A matching rule encapsulates a set of logic that may be used to perform some kind of matching operation against two LDAP values
For example: Directory String, Integer, and JPEG are examples of standard LDAP syntaxes.
For example: Comparison, Sort and Order
Protocol Overview
A client starts an LDAP session by connecting to an LDAP server, called a Directory System Agent (DSA), by default on TCP and UDP port 389, or on port 636 for LDAPS.
The client may request the following LDAP operations:
Operations
Explanations
StartTLS
Use the LDAPv3-TLS connection
Bind
Authenticate and specify LDAP protocol version
Search
Search for and/or retrieve directory entries
Compare
Test if a named entry contains a given attribute value
Add
Add a new entry
Delete
Delete an entry
Modify
Modify an entry
Modify Distinguished Name (DN)
Move or rename an entry
Abandon
Abort a previous request
Extended Operation
Generic operation used to define other operations
Unbind
Close and exit the connection
LDIF
LDAP Data Interchange Format (LDIF) is a standard text-based representation for LDAP data.
LDIF conveys directory content as a set of records, one record for each entry.
It also represents update requests, such as Add, Modify, Delete, and Rename, as a set of records, one record for each update request.
This is an example of a simple directory entry with several attributes, represented as a record in LDIF:
dn: cn=John Doe,dc=example,dc=com
cn: John Doe
givenName: John
sn: Doe
telephoneNumber: +1 800 800 8888
telephoneNumber: +1 800 800 9999
mail: jdoe@example.com
manager: cn=Eliza Beth,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
Other Useful Notes
In LDAP 3.0, there is a special root called rootDSE (where DSE stands for “DSA-specific entry”) is defined as the root of the DIT server.
The purpose of the rootDSE is to provide data about the directory server itself.
i.e., rootDSE is not part of any namespace, but it contains namingContexts, which provides a list of all DNs in the the DIT.
Directory servers publish internal schema as an entry in the directory.
It can be retrieved by LDAP clients performing a baseObject search on the a special entry that is defined by the directory server to publish schema information (e.g., cn=schema), with the attributes attributeTypes and objectClasses specified as part of the search criteria.
Each LDAP directory has some default schema, which developers can customize, or “extend,” by adding elements to it.
Code Fluence 