What is the difference/relation between ADAM, Active Directory, LDAP, ADFS, Windows Identity, cardspace and which server (Windows 2003, Windows 2008) uses what?
Active Directory is a server component for administrating windows domains and storing related informations like details about users. It provides implementations of the network protocols LDAP, DNS, CIFS and Kerberos. It's part of Windows Server 2003 as well as Windows Server 2008 with some modifications in the latter case.
ADAM was somewhat like the little brother of Active Directory. It only contained an implementation of LDAP. With Windows Server 2008 it was renamed to LDS, Lightweight Directory Services. ADAM/LDS can also be installed on non-server versions of Windows.
LDAP is a protocol for administrating the data of a directory service. Data within a directory services are stored in a hierarchical manner, a tree. Entries within that tree can contain a set of attributes where each has a name and a value. They are mostly used for storing user related informations like usernames, passwords, email addresses and so on, as there are standardized schemas for this purpose and it's widely supported by applications.
ADFS is a technology which enables Single Sign-On for users of web applications within an Identity Federation. In a very short form: Imagine two organizations which have their user data stored within an active directory. Now each organization wants to give the users of the other organization access to its web applications, but with the restriction that the user data itself should neither be copied nor be fully accessible to the other organization. Thats the kind of problem ADFS can solve. May require an hour of reading & researching before fully understood.
Just to fill in the gaps above:
ADFS is an example of a STS (Security Token Service). STS's can be configured to have a trust relationship with each other. Imagine you have a company which only has internal users and they want to expand to external users. That means that all external users have to register, get a user name, password etc. Perhaps the company doesn't want to store all this stuff. They realise that most of their external users already have an OpenId account. So they federate (trust) their ADFS with an STS that accepts OpenId credentials.
When an external user wants to access the company website, they are asked what kind of user they are via a drop down. They select OpenID. They are then taken to the OpenId site where they authenticate. The user is then redirected back to the company ADFS with a signed token which states that OpenId has authenticated the user. Since there is a trust relationship, the ADFS accepts the authentication and allows the user access to the web site.
None of the OpenId credentials are stored by the company.
Effectively, you have outsourced authentication.
ADFS currently runs on Windows Server 2008 R2.
For Windows Identity (in the context of ADFS) I assume you are asking about Windows Identity Foundation (WIF). This is essentially a set of .NET classes that are added to a project using VS that makes the application "claims aware". There is a VS tool called FedUtil that maps an application to a STS and describes the claims that will be provided. (A claim is an attribute e.g. name, DOB etc.) When a user accesses the application, WIF redirects the user to the mapped STS where the user logs in. WIF then provides the application with a set of claims. Based on these, the application can alter flows based on the user claims. E.g. only users with a claim type of Role with a value of Editor can alter pages.
WIF can also act as an Access Manager E.g. only Editors can access this page. Other users simply receive an error.
In WIF, an application is referred to as a "Relying Party" (RP).
WIF inside VS requires Vista or Windows 7.
Since STS's can be federated with each other, each STS can provide a group of claims.
E.g. in the example above, the OpenId STS can provide the user's name while the company ADFS can provide information not pertinent to OpenId e.g role in the company.
Cardspace is a mechanism to authenticate via a digital identity e.g. an enabled application can ask you to login by selecting one of your "cards", one of which might be e.g. your personal X509 certificate. The application would then check this against the credentials it has stored.
In February 2011, Microsoft announced that they would no longer be developing the Windows CardSpace product.
Related
I have registered an app in AAD and as a admin I want to provide permission for user to read or access the data of particular group list not all group available in my MS team account. How can be achieve this any idea?
No. Azure AD app doesn't provide such a feature that scopes Microsoft Graph application permissions to specific Microsoft Teams/Groups.
The client credential flow is used to as an authorization grant typically when the client is acting on its own behalf. When you give Group.Read.All or Files.Read.All or other similar application permissions, it means the client has access to all the files/groups across the entire tenant.
You can achieve this by implement the business logic in your code. For example, providing a configuration file which includes the particular groups'/teams' object ids. And then restrict the access for users to only these groups/teams by checking if the object ids (which users are trying to access) are in the configuration file.
Is there a way to detect and monitor that a service principal is only being used from a specific set of IP addresses? I do not want to IP restrict my entire directory. I have premium AAD and I think it has features that I might be able to utilized but I cannot do much testing. I’m currently struggling on how to detect if a SP has been jeopardized and how to prevent it.
If you want to use IP as conditions for the user to sign-in, you could use Conditional Access to make it. But the Conditional Access is used for the entire tenant.
And the features of Azure Active Directory Premium includes:
Company branding
Group-based application access
Self-service password reset
Self-service group management
Advanced security reports and alerts
Multi-Factor Authentication
Forefront Identity Manager (FIM)
Enterprise SLA of 99.9%
For the details, please read here.
I have a multitenant ASP.NET application using OpenIdConnect and Azure AD as an Identity provider for Office 365. When the user is authenticated I receive my claims in ClaimsPrincipal.Current.
I wanted to identify a user and store this id reference in my database. I asked this question.
It was replied that
When trying to identify a user uniquely [NameIdentifier] should be your go-to choice.
But it seems that the NameIdentifier claim, http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier
depends on the application. Precisely, if I create another application in Azure AD then, the NameIdentifier will not be the same for the same real Office365 user. Keep in mind that the we may have to create another Azure AD manifest (because we could need other scopes) and we should be able to find back the same end-users.
Meanwhile, I remarked another claim: ObjectIdentifier http://schemas.microsoft.com/identity/claims/objectidentifier
It seems that ObjectIdentifier, is the same for all Azure AD-secured application for a given Office 365 user.
Can you explain precisely the difference between those two claims? And more importantly, can you confirm that the ObjectIdentifier can be used as an "universal" identifier for a user in any Office 365 subscription.
Precisely, if I create another application in Azure AD then, the NameIdentifier will not be the same for the same real Office365 user.
I made a quick test as following:
Register a multi-tenant-webapp and single-tenant-webapp in AD Contoso.
Log in with user1#contoso.onmicrosoft.com and get the name identifier in both web applications, it turns out the name identifier are the same in both applications. So the name identifier should be able to identify users cross applications, but it can not be used to identify the user in Azure AD.
For the object identifier, it is a GUID which you can used to identify a user in Azure AD. For example, you can use object identifier to query the user in Azure AD.
Powershell:
$msolcred = get-credential
connect-msolservice -credential $msolcred
get-msoluser -ObjectId "{guid:object_identifier}"
And more importantly, can you confirm that the ObjectIdentifier can be used as an "universal" identifier for a user in any Office 365 subscription.
Based on my understanding, the object identifier is a GUID which can identify for a user in Office 365 subscriptions.
Or to put it another way:
The NameIdentifier is the GUID of the Application which is registered in Azure AD. This won't change whether it's a single or multi-tenant application. It won't matter if you are using client credentials (i.e. AppId and AppSecret) to authenticate AS the application or using logging using real user credentials (i.e. delegated), the NameIdentifier will remain the same.
The ObjectIdentifier is the User Principal Name (UPN) for the user when using delegation or Service Principal Name (SPN) of the application when using client creds.
The reason you see different ObjectIdentifier values when an application is multi-tenant is that there is a separate and unique SPN in EACH TENANT which points back to the ApplicationGUID in the tenant where the application is registered. This SPN is used to assign rights to the application against resources in each tenant.
I have to implement Single Sign on with following user case:
We have three kinds of users:
1) Corporate employees [Stored in Active directory]
2) Clients can access our application
3) We have hosted separate application for each client and clients employees can access this application [hosted on our server] and number of employees can be have million.
So we cannot store use credentials in active directory because we need per user license to use.
Please help me to find better solutions
ADFS only works with AD. The next version of ADFS will work against LDAP so that's a possibility.
I would look at Azure Active Directory (you could use something like AAD Sync. to migrate your existing AD users) or something like OpenAM or PingFederate (both of which are Java based) which you have to pay for or something like shibboleth (Java based but open source). These all support LDAP.
Or if you want to go the SQL Server route, look at thinktecture's identityserver.
I believe Windows auth is the best practice to use to connect to SQL DB. I am hear talking about application user account..
Is it true that SQL auth is only great for multiple role apps and window auth is only good for single role app? I never heard that windows auth with muitple role os only good for smaill internal app?
multiple Windows logins = multiple connections = no pooling = poor scaling?
The problem with using Windows auth for a web application is that many web applications store their application users' credentials in the same SQL database that is used for other application data.
So you have a chicken-and-egg problem. You can't authenticate the user before connecting to the database, and you can't connect to the database without authenticating the user.
It should be possible to use Windows authentication, and then also have application-specific attributes of the user stored inside the database. But most people find this cumbersome to administer, and also limiting to portability of the application.
For example, if one of the feature of the application allows users to change their own password, then the process running your web application needs the privilege to alter a Windows password, which may mean that the application needs to run with Administrator privileges.
If you let the application manage user ID for the context of the application, then to change a user's password is just an SQL operation, and your application is in charge of enforcing security for that.
I'm not sure what you mean by single-role and multi-role app. I have built apps before where there are multiple SQL Server Database Roles, each with a Windows Domain Group of users allowed in that role. So user management is completely within Active Directory, with a 1-1 correspondence between the Domain Group and the Database Role.
We typically did not manage the security within the application itself except obviously declaratively during the database creation where each object was granted access by particular roles according to the design. Typically, in a simple case, we relied on db_datareader role being granted for general usage to non-specific groups of users like database and network administrators for troubleshooting or report-writers or business analysts for ad hoc reporting. Actual users of the app would be granted execute on the relevant SPs to be able to modify any data (so all data creation or modification was through SPs and only explicit members of the ThisAppsUsers AD group could do it). Any advanced SPs (say, merging or deleting accounts) would only be accessible by ThisAppsAdmins AD group. And that was usually all we needed for moderate-sized applications. For more complex functionality, it was also possible to interrogate AD directly for custom attributes (user is an admin only for this customer account but for others is just a user)
This same technique can be used with SQL Server logins, but of course the individual SQL Server logins have to be added to the database roles, and you don't have the richness of AD and have to build some kind of directory service into your database.
The ability to even use AD may not be possible for many applications, so in that case, the security architecture would obviously have to cater to that model.
using the integratedSecurity=true option for SQL JDBC , by including the JDBC auth .dll, should give you database connectivity without authenticating...