openid - Design of IdM and SAML -


company has acquired company b. company & company b users have authenticated using federation. example, think company microsoft , company b skype. both microsoft(livemessenger) , skype has users registered im. microsoft has provide unified experience customers. how can solve problem using federation? there can be:

1) skype users 2) live users 3) live , skype users

at end, customer should log in once , can log in skype or live messengers. should not ask login again.

now, live service , skype service relying parties. skype , live expects application specific tokens rest based communication.

as developer @ microsoft, understand need create idm. need migrate existing users live , skype idm? or should idm call user management service of live , skype in background?

i understand need exchange saml token application specific token, how should done? need expose service endpoint @ skype , live services?

there 2 sides problem:

identity , entitlement management

the first 1 called identity , entitlement management , deals modeling of users exist, how can authenticated , can access. there 2 ways approach situation:

  • in first approach end single corporate-wide identity users (think of single google account giving access sorts of google services). far provides best user experience, requires migration of users, new registration processes, ...

    you introduce new centralized authentication service (an identity provider, idp), each user has account enables access services of company (which user has entitlement access) using single sign-on.

    you migrate existing users skype idp (i.e. current skype accounts directly allow authenticate @ idp). , enable registration process allows user establish new account @ idp first authenticating (now legacy) live credentials. of course choose different "default" account, try merge both of them together, or require each user register anew.

  • in other approach want enable single sign-on (= users able access applications single authentication), want keep accounts , registration processes intact.

    again, want create identity provider, time allow users select whether authenticate using existing skype or live account. after selection, verify credentials selected service (e.g. using application's apis, or other available way). users still register used directly in skype/live services.

identity federation

the other side of problem called identity federation , in core deals problem of connecting applications (relaying parties or service providers - different terms same concept) idp service; in other words externalizing authentication.

and here starts discussion different federation protocols, such saml, saml 2.0, openid, (partly) oauth 2.0, ws-federation, custom protocols, ... different ways same thing - securely transfer information fact user authenticated between 2 systems.

you should select 1 of these protocols , enable applications support (either directly modifying applications, or using proxy routes access application , able support selected protocol - e.g. iis or apache plugin). typically exposes set of endpoints @ application able accept messages sent idp (e.g. saml messages).


Comments

Popular posts from this blog

commonjs - How to write a typescript definition file for a node module that exports a function? -

openid - Okta: Failed to get authorization code through API call -

thorough guide for profiling racket code -