Identity can be defined as a set of attributes that describe a person or an object. It may also include information on the relationships with other identities.
When we speak about an identity framework, we normally have three different components that interact together:
Relying Party ( might also be referred as SP Service Provider )
When Users access to services ( in identity terminology accessing to Relying Party ), there is the need for authentication and other attributes for those users. That information is provided by the Identity Provider ( IdP ).
Today we hear a lot about Federated Identity, which is the process where we link the User and it’s attributes with a distinct Identity Management Systems. Most of the times we are just talking about Single Sign-On, where the user authenticate itself against an IdP, which generates a ticket or token that will be used by other systems inside and outside the organization, without the need for the User to re-authenticate.
There are multiple protocols today that allow those three components to interact with each other and how they interact with other organizations, for example: SAML, OAuth, WS-Federation, OpenID Connect, Shibboleth, Liberty Identity Federation Framework, etc.
A brief description on the protocols that are more used and well known in the Industry:
SAML - A set of standards that have been defined to share information about who a user is, what his set of attributes are, and give you a way to grant/deny access to something or even request authentication. Allows for two different organization to establish trust relations without exchanging passwords (http://www.oasis-open.org/committees/security)
OAuth - An open standard for authorization. It is more about delegating access to something. You are basically allowing an application to impersonate you. It is used to grant access to API's that can do something on your behalf. For example, you want to write an application that will use other applications like twitter, Gmail and Google Talk (http://oauth.net/)
OpenID Connect – It is an emerging protocol, focus on simplicity for SP ( Service Provider or Relying Party ) and based on OAuth 2.0. It is a suite of lightweight specifications that provide a framework for identity interactions via REST like APIs. OpenID Connect is built on best practices and years of deployment experience of OpenID, Oauth, SAML, PKI (http://openid.net/connect/)
In part II of this blog we will cover why does Identity matter for a Collaboration solution.
Hi All, I am in SRST mode, my 2 phones are correctly registered on VoIP GW /Routr(ISR4331) but I get following error from ISR4331: No matching outgoing dial-peer DN are 60401 & 60402(correctly SIP registered) Below my config FIX1-V...
Hello all, we are currently deploying a CUCM BE6000 for a customer. We only have a couple of active users, however the customer AD is pretty big (huge, actually, >40k entries). We would like to sync CUCM to AD. It would be best to sync all us...
Hi All.. I have TMS 15.9 and CMS 2.6.2 configured, with scheduling working etc.. When Meeting are scheduled either by the TMS 'Add Conference' button or the Smart Scheduler.. although the owner is listed. This doesnt seem to flow across to the C...