Authentication vs. Authorization explained

There is a fundamental difference between Authentication and Authorization. Authentication is the mechanism whereby systems may securely identify their users. Authentication systems seek to provide answers to the questions:

• Who is the user?
• Is the user really who he/she represents himself to be?

 Authorization, by contrast, is the mechanism by which a system determines what level of access a particular (authenticated) user should have to resources controlled by the system. For an example that may or may not be related to a web-based scenario, a database management system might be designed to provide certain specified individuals with the ability to retrieve information from a database but not the ability to change data stored in the database, while giving other individuals the ability to change data.  Authorization systems provide answers to the questions:

• Is user X authorized to access resource R?
• Is user X authorized to perform operation P?
• Is user X authorized to perform operation P on resource R?

SSO falls in the authentication category – this is the segment we are not operating in. Microsoft, Okta, Sailpoint, Ping, OneLogin and many, many other vendors operate in this segment.

IDdriven operates in the authorization category and all the things around authorizations (certification, compliance, RBAC, reporting, self service etc.) – because the complexity is much higher in this segment the amount of vendors is smaller too. Some of the above-mentioned vendors also overlap to this category and offering their service or software as IDaaS.  Since IDdriven has complete focus on the authorization segment, we offer an incredible amount of functionality compared to other vendors.

The question you might have is why does IDdriven not have an offering in the authentication segment (SSO)?

The simple reason is that many firms in this segment and requires significant investments (both development and ongoing operational costs) where the end result is a product that offer the same as all the other competitors who give this functionality away for practically free. The reason why we don’t offer SSO since our customers get that from Azure.

Let me first clear up some terminology:

Azure: This is Microsoft’s cloud (Virtual Machines, databases, networks, clusters, storage, monitoring etc.), basically the nuts and bolts.

Office 365: The term ‘office’ is a bit misleading here since it reminds you of Word and Excel whereas in reality it is part of a much bigger suite of cloud products, including Azure Active Directory. Every Office 365 customer has (automatically) its own Azure Active Directory where users and security groups are stored.

Azure Active Directory: Azure Active Directory (AAD) is ta company directory containing employees, security groups, distribution groups (email), the new Office 365 groups and departments. It’s the company ‘database’ which is used in Office 365 for authentication purposes, but also to give employees access to resources in e.g. SharePoint online or other applications. AAD has been such a success that Microsoft is renaming AAD to simply ‘Active Directory’, replacing the good old on premises variant of Active Directory soon. Companies are synchronizing their on-premises Active Directory to AAD in the cloud using a tool called ‘AAD Connect’. AAD Connect synchronizes the users and groups that exist on premises to the cloud to help companies in this transitional hybrid period, where companies live both on premises and in the cloud. AAD is significant for IDDriven for two reasons.

1.       IDdriven uses AAD for authentication purposes. The user must log in with his/her ‘Organizational Account’ (work username/password) from AAD to get access to IDdriven. IDdriven does not see or know about this password – it’s simply waiting on AAD until it gives the nod that the user is verified. When IDdriven has received the ‘nod’ from AAD, it’ll log the user in, without knowing or having checked the password of the user since IDdriven trusts AAD to handle this.

2.       IDdriven synchronizes data from and to AAD. When a new employee is added to AAD, it is added to IDdriven. When IDdriven dictates that a user should be a member of a security group in AAD, it’ will synchronize this to AAD. When an employee is disabled in IDdriven because of a gross misconduct, the user loses all his access rights in AAD. Etc. etc. We add automated security and compliance at a much finer grained level that Microsoft offers.

SSO can be configured in AAD so that users who login to their organizational account can automatically log in to other apps (like DropBox) without the need to enter their credentials again. They will also be presented with a dashboard containing these apps which saves the employee having to make browser shortcuts.

SSO is not a prerequisite or requirement for IDdriven or other IDaaS / IAM products, although they are often associated with them.

A customer could use SSO of any other vendor (or no SSO at all) in combination with IDdriven, however currently IDdriven needs Azure Active Directory for authentication purposes.

 Hope this provides useful information and further context where we fit in to your IT security equation.  Look forward to your feedback.