Meeting the InCommon Assurance profile criteria using Active Directory

["Rank, Mark" <>]

 

Folks:

 

Taking Brian's descriptions and the functional model on pg 4 of the IAAF (https://spaces.internet2.edu/download/attachments/33816578/IAAF-V1.2-CLEAN-Jan2013-RC.pdf), I might propose the following initial mappings to start the discussion/debate... I sorta punted on Azure... Feedback welcome.

 

Please advise,

Mark

 

AD-DS

                Domain Services. This is what most people are referring to when they say "Active Directory", and was the only "Active Directory" until the Microsoft branding machine got carried away (as it always does). AD-DS stores passwords, issues logon tokens, provides LDAP directory services, and via extension of its directory services can also provide other services such as DDNS, certificate authority, etc. Note that on a per security identity basis, AD-DS supports more than just password based authentication--including both external Kerberos realms and certificate based authentication. Also note that AD-DS can trust other identity providers--this is usually other AD-DS instances.

 

(Attribute Service) - In Scope

(Verifier) - In Scope

(non-IdP Apps) - out of scope

 

 

AD-LDS

                Lightweight Directory Services. This is AD-DS without the network operating system specifics. In other words, a LDAP directory service that you can almost fully modify. AD-LDS can be used in conjunction with AD-DS, to extend AD-DS. Depending on how AD-LDS is used, it might store passwords or simply act as an authentication proxy to AD-DS.

 

(Attribute Service) - In Scope

(Verifier) - In Scope

 

AD-FS

                Federation Services. This is Microsoft's federated authentication provider. It does not store passwords. It only supports two identity claims providers: AD-DS and SAML claims providers. ADFS is subtly different than Shibboleth, but can interoperate with Shibboleth. AD-FS facilitates authentication, issuing the equivalent of a logon token, but it doesn't actually do the authentication.

 

(IdP) - In Scope

 

AD-RMS

                Rights Management Services. This is Microsoft's DRM product. Application specific data is encrypted specific to a user or group of users, and can only be decrypted when the specific application specific restrictions on that data are satisfied. The most commonly known example is not being able to forward Steve Balmer's company-wide email outside of Microsoft. No password storage or authentication here.

 

(non-IdP Apps) - not in Scope

 

AAD

                Azure Active Directory. In general, you synchronize your on-premise AD-DS with Azure Active Directory, but there are a lot of details. There are multiple components under the cloudy hood. They are: MSODS, OrgID, and ACS. MSODS is a highly customized fork of AD-LDS about which little has been publicly disclosed. My understanding is that MSODS doesn't store passwords or issue logon tokens. OrgID is a parallel instance of the Microsoft LiveID system (LiveID was re-branded Microsoft Accounts), but is *not* a consumer focused system, but instead for enterprise customers. OrgID issues logon tokens, and depending on your AAD configuration may or may not store passwords. ACS is Microsoft's cloud version of AD-FS, except on steroids. ACS supports many more identity claims providers including almost every social identity provider, and can do much more than AD-FS. Like AD-FS, ACS issues the equivalent of a logon token, but doesn't do the authentication itself. Note that the AAD tenant owner has the option of either storing passwords in AAD or not. Note: I am aware of no public knowledge about how those passwords are stored. You must setup federated authentication with AAD to avoid storing passwords there. Finally, even if you elect to not store passwords in AAD, there are several *common* scenarios where a user's password will be sent to Microsoft Cloud systems. In specific, most of the "active profile" use cases (e.g. Outlook and Lync) with Exchange/Lync Online involve sending the password to the Exchange/Lync Online server so that it can get a federated logon token on your behalf. To be clear, those Microsoft Cloud systems aren't part of AAD, rather they are part of the set of services Office 365 provides. Every Office 365 deployment leverages AAD.

 

(Attribute Service???) - In Scope

(Verifier???) - In Scope

(Service Provider ???) - Out of Scope

(non-IdP Apps ???) - out of scope

 

 

Mark Rank
Project Manager - Identity & Access Mgt

UCSF Information Technology Services (ITS)
email:

phn:414-331-1476