I am trying to migrate one of our solution from a Laravel/PHP system to a .Net Core 2-based system. My main problem is regarding Authorization and Authentication.
I have 5 different apps that send REST queries to the Api (e.g. Web Browser, iOS Apps, Android Apps, etc.) and the way I currently handle authentication/authorization is as follows:
A user sends a Username/Password, as well as an App Id (e.g. 'Browser', 'iOS', etc.) and an App description (e.g. 'Chrome-Jacob', 'iPhone-7-Jacob').
If a Token already exists for the pair of App Id / App Description, it is returned. Otherwise, a new token is generated and saved in a Database table named 'Tokens'.
Each token can have a different matrix of permission, which is very granular (e.g. 'Users/ViewAll', 'Users/Create', 'Users/ViewOne', 'Users/ViewMe', etc.)
When a REST query is received with the token in the header, we look for the token's permission matrice in the database and try to see whether the intended feature to be accessed is authorised or not.
It seems that in Core 2, the intended use of token is through JWT. I'm not 100% comfortable with this approach, because I want the user to be able to see all tokens that were generated for his access, all associated permissions and the ability to simply revoke access to a token; whereas with a JWT, it is impossible to know who has what token, until they send it in a request.
My current implementation can generate any random token as long as it's unique in database; it doesn't necessitate any encryption algorithm.
What would be the best approach to replicate the system above in Core 2 ?
I find Microsoft's approach very good for simple applications but I am struggling to override the Authorize Attribute and get the granularity that I wish for.
I find Microsoft's approach very good for simple applications but I am struggling to override the Authorize Attribute and get the granularity that I wish for.
That's quite the opposite. Microsoft did not invent nor were close to the first to start using JWTs. You have taken something that is very common and made your own version of it, something that's not considered secure nor a good practice.
There are two ways to solve the problem at hand:
Using Identity Server 4, a free, open-source system made for ASP.NET Core, made by highly experienced security people, which provides you a customizable OAuth 2.0 / OpenID Connect system. With this, you would need to rework, some parts of the security of the applications, but you would be using industry standards.
Note: this might not be too easy, but scales extremely well
Identity server already gives you all the information about each application and which tokens are valid for which.
While you could do this by hand without too much trouble, I would suggest you to look at ASP.NET Core Identity, the official framework for Authentication and Authorization in ASP.NET Core. Notice that, regarding how to know which tokens/logins are active, Identity recently adopted two interesting tables:
IdentityUserLogin: tells you what users logged in where/how
IdentityUserToken: gives you the tokens that have been provided for a given user.
All this said, it's common to add ASP.NET Core Identity to an Identity Server 4 application, given that the later is not for handling authorization.
Related
After hours reading about JWT I am more confused than before starting. Why are jwt being so used if they are not secure within a stateless application? I understand that if a hacker stoles the JWT from a valid user, then that's it, game over.
I am currently starting building an e-commerce with reactjs , and I am struggling with many things. What I want to achieve is two have multiple apis (asp.net web api projects) working (ProductsApi,PaymentsApi, etc..), kind of a reduced version of microservices (without struggling with the communication, api gateway and others things from the beginning ). So, in order to accomplish this I need that a user after putting its username and password, be authorized to use the correct apis. So far I am able to generate jwt that can be validated by all the api projects (https://bitoftech.net/2014/09/24/decouple-owin-authorization-server-resource-server-oauth-2-0-web-api/). So, what I understand is that I have two options:
Stateless application: Get the jwt from the authentication server and save on localstorage, so it can be used when accessing the apis. (insecure as hell)
Reactjs inside a Asp.net MVC(Server side rendering): Use cookies (httpcookieonly) to access the apis.
The way I see it, the best approach is #2, so I was planning to still use the jwt thing, BUT adding a claim to it with the sessionid generated by asp.net MVC. Would that make the jwt "secure"? Can it still be stolen and used from another person?
I know I am talking about many things at the same time. It's just I am so confused right now, and I dont find any good post on internet that can suit my needs.
https://identityserver4.readthedocs.io/en/release/intro/support.html
I currently issue tokens myself in my web api with JwtSecurityToken and I use standard ASP.NET Core middleware calling AddJwtBearer to verify the tokens. It works fine.
What advantage will give me using OpenID Connect (through IdentityServer4) over the approach described above? How to answer myself question "Do I need OpenID Connect?"
From my basic understanding about OpenID Connect, it is used to allow third parties to access your API. But I make API for myself and not for third parties and I don't know why should I favor IdentityServer/OpenIddict over my simple approach.
I read that if I want Single sign-on I should use this, but JWTs itself aren't bound to any specific domain and I can use single sign-on with just pure JWTs(they're self-contained)
I understand it implements some kind of standard for issuing tokens. (protocol). It might be good if I ever wish to expose some API to third parties. But for internal APIs? Is it worth using it?
This is my current auth flow (from https://jonhilton.net/2017/10/11/secure-your-asp.net-core-2.0-api-part-1---issuing-a-jwt/)
What I really want to implement to secure my Web API:
Login
Logout (invalidate token?)
No consent screen (want to have API only for myself), auth happens in the background in my native desktop, mobile, web app (no redirection)
Remember me feature (refresh tokens?)
Could someone clear out the fuzzy picture of OIDC/OAuth2 for me? i.e. give me some disadvantages going my own way (implementing my own flow) and advantages of using OIDC in place of my own flow.
What will it save me from doing later on (on the client-side for example), and what will not. And most particularly, is it good to start every project using standard flows like OIDC? Will it somehow benefit me in the future?
In any case you will implement OAuth2. Think of Oidc as an extension of OAuth2. The most important thing to keep in mind is seperation of concerns.
Forget Oidc, Identity Server 4 is all about authentication: "who is the user"? Consider Google login. When a user logs in for the first time, the application doesn't know the user, it only knows that Google does.
Authorization takes place on a different level and isn't really a concern of IdentityServer. For that you could take a look at PolicyServer.
So you'll need to keep the user database seperated from the application database. This doesn't mean you need another database, just don't mix contexts. If you have a relation from the "business context" to e.g. the user table in the "Identity context" then you are going to have a problem eventually.
In your setup your web api is both the resource and the identity provider. This means that every new web api you create has to be implemented as both resource and identity provider. For maintainability you could create a seperate web api that acts as an identity provider, while the web api is a resource only. You can implement something like that as long as all apps can read the token.
The same counts for the front. Why should the front have anything to do with the user? All it needs to do is pass the token in order to get the user authorized. In case of IdentityServer, the app contacts it to verify the user and receives a token. It knows nothing about credentials. This is more secure. The client app can be compromised. The credentials can be intercepted.
Having single apps with a specific concern makes things more maintainable. And it is quite easy to add a new resource without having to code when you use IdentityServer. Just add the configuration. It also allows you to add other flows in the future that are not needed at this time. And as a side note, the consent screen is optional.
The bonus is that you can implement SSO, where in your setup that could be harder, if not impossible.
So you don't have to use IdentityServer, nor Oidc. Your setup may be just fine. But if you build something, keep seperation of concerns in mind.
I'm working on a solution with others where we have built on a Visual Studio Web Project using MVC (5 I think) and WebApi2.0.
The nature of the solution is that it has 2 DALs, one of the DALs uses SQL to access another applications database, the other DAL uses entityframework codefirst to manage our applications database. There is also a service that is associated with the project so we have done our best to adapt the entire solution into a 3 tier pattern. This means there is a project that contains our BusinessLogic and both our service and our Controllers use it to access the DAL.
So all that out of the way...We are now adding in authentication on the web side. We were stuck for days until we really just embraced Microsoft's default project structure with the OWIN authentication. The downside is that we now have a separate User database that is essentially coupled with the Presentation/Web layer of the solution.
Is there any way to keep all the convenience of the default OWIN authentication in the MVC project AND abstract it out into the LogicLayer? I can't post what we've worked on, but needless to say it's failed every time because we are really struggling to identify what is being done for us behind the scenes (one example is the [assembly: OwinStartupAttribute(typeof(AlarmAggregator.Startup))] annotation). This annotation alone makes me think we will NOT be able to abstract it out.
I know I'm asking to have my cake and eat it too, but I was hoping someone had some insight if it was possible.
At the very least we were hoping there was a way that we could combine our internal database and our user database? I think this would have to happen at the context level? Would it be as simple as pointing our web.config at our internal context?
Since you have not mentioned what those 2 databases are, I assume they are not user databases and out of context. Focusing on the user identity storage, yes its going to be a separate entity unless you are using ADFS, LDAP or something. I would discourage you from building your own identity solution, rather look out for something more widely used and accepted because its a security topic.
Take a look at Thinktecture Identity Server. Its an OpenId Connect based open source solution built in .NET. It comes with its own database, supports same domain SSO, cookie based authentication and supports open id connect. It also supports federated authentication if you want to hookup a ADFS. Its also possible to do social sign in integration with it.
I have integrated .NET, Java and PHP solutions in production to the same instance and everything is fantastic and seamless.
You can host it as a separate service. You can register known clients (your apps and services), their incoming and redirect urls, including post logout Urls, so your application can seamlessly reach out and come back from identity server. The Identity Server comes with all the middleware you would need to protect your APIs and web applications. It also provides REST endpoints for getting and validating access tokens amongst others.
You can also set different scopes to specify the scopes against which a request can be processed.
Much of what I am talking about has directly to do with oAuth 2.0 specs so probably you can read a little about it here if you are not aware of it.
Using a typical oAuth Flow, (e.g implicit flow or authorization code flow), hooking up the right middleware in the Owin pipeline, and decorating your API resources with [Authorize] attribute, your Application will redirect to the identity server page where the user can login. Your APIs(the protected resource) can specify if they are expecting for a specific Scope, when a token is presented and allow to accept/deny your request based on that.
The client registration ensures that only known clients are accepted by identity server(as applications are generally internet facing) and you can either use the MembershipReboot component, also from Thinktecture(also opensource) as your identity store or write your own implementation of a "user service". There are way too many extension points available to play with and you can practically customize everything including the look and feel of the identity server pages to match the UI scheme of your client applications. There is IUserService(to plugin your own user store, ViewLoader to customize UI, CORS policy service to specify allowed origins per client, certificate based TokenSigningService to sign tokens(access/refresh tokens), ScopeStore, ClientStore, TokenHandleStore(to store scopes, client configurations, tokens), ClaimsFilters to filter what claims are included when a token is issued, which is helpful when you use external providers which might return more information that you need to store or provide)
I can go on for ever here but like I said its something available for use and I am using it for multiple applications in production, you can give that a try.
You can have it up and running in 30 mins on your local machine with both Identity Server and MembershipReboot databases setup. The support is very good from the authors and this is a very widely accepted solution for user authentication and authorization.
For example, securing a WebAPI is super simple:
decorate your APIs with [Authorize] and or [ScopeAuthorize] based on your need
This tells the API to go and check if you got something setup for Authorization in the owin pipeline.
In Owin startup just use:
app.UseIdentityServerBearerTokenAuthentication(new IdentityServerBearerTokenAuthenticationOptions()
{
Authority = "http://your-idserver-url"
});
Yes that is all the change you need in your WebAPI. There is a separate way to setup open id configuration for MVC based web applications but that is anyway available in the documentations with sample code.
The documentation is pretty easy to follow and the server is easy to setup. It takes away all the complexity from your App and services so you can focus on what you want your App to do rather than worrying about handling Authentication and Authorization in each of your Apps or services.
What are the best practice for implementing authentication for REST apis?
Using BASIC auth + SSL or something like https://datatracker.ietf.org/doc/html/draft-hammer-http-token-auth-01?
Are there any existing solutions available (for .NET / WebApi)?
The answer on this depends on the audience for your Web API and what you want to authenticate exactly.
Do you want to authenticate a client application that uses your Api?
Do you want to authenticate a user from your application to retrieve their data within a client application (using your Api)?
Or do you want to authenticate both the client application and the user using the client application.
Depending on what you want to authenticate you have multiple options. But always keep in mind that it is better to go with a solid solution where many client libraries are available than reinvent you own. Never do a little off this, but in your own way, chose one way of authentication, stick to it and don't break the client libraries.
Basic authentication: Is very easy to implement, but you authenticate a client app with it, not a user. This kind of authentication is nice when business trust relation needed and authentication and safety is not your very first concern. But there is no way to track a call in your API back to a certain user, just a client application. Of course you could save your user's username and password in a client application but this is a bad practice in more then a single way.
Token based authentication: Their are many ways of token authentication but the one i'm talking about here is a single token for a user which the user copies to the client application to get access to your Api. This way you can authenticate a user (who made this call in my Api?) And it is fairly easy to make and use. The withdrawal is that it is not the most secure way, requires user interaction and that a user possibly uses his Api token in more then one application. You could extend this way of authentication with basic authentication to authenticate a client. So a clientid + clientsecret + token to identify the user. But I think if you want to accomplish this it would be better to take a look at Oauth2.
OAuth2: If you want to have full access over your authentication you can go this way. It is possibly the most future proof way to go, but also requires the most work (at least at the identity provider/resource provider side. The client application has a fairly easy time implementing this with a lot available client libraries. If you go with this way of authentication (also token based) you can authenticate the client and the user, without the need to share your users username and password.
My recommendation: would be to go with Basic Authentication if this fits your case, it is easy and together with HTTPS is fairly safe. If it doesn't fit I would go with Oauth2 because it is the most solid and used standard (Instagram/Google/Facebook), gives you a lot off freedom and with a growing ecosystem gets easier and easier to implement. After all for someone implementing your API it is way more interesting to learn something about Oauth 2.0, then learn about the jgauffin way of doing things.
Reference: I would also like to invite you to have a look at Apigee's website. Api's are their business and they have quite some interesting reads. One of them is is a free ebook - Oauth the big picture which also has a interesting paragraph where they ask if you really need Oauth. (From page 16 - Is OAuth all you need for API security?)
For server-to-server APIs - APIs designed to be used only by a small number of servers –
OAuth is overkill. Having a separate set of authentication credentials for each app is a nice
feature of OAuth, but for server-to-server use, the need to log in securely using a browser,
or to implement other steps in the OAuth “dance,” gets in the way.
Instead, using a simple security standard like HTTP Basic authentication and assigning a
unique password to each app is sufficient. Two-way SSL is another good, albeit
cumbersome approach that has the advantage of stronger, more traceable authentication.
However, think ahead! Are those APIs really only going to be used by servers forever?
Exisisting Solutions: Whatever way you go leastprivilege - Dominick Baier and his nuget packages can give you a nice headstart. Implementing basic authentication using his Identitymodel is really easy. Also if you want a ready-to-go identityserver to provide you with tokens look at his identity server which does all you can think off. However if you decide to go for Oauth2 I would also have a look at DotnetOpenAuth since it is (imho) a bit more configurable and easier to tweak to your own like, but it also takes more work.
You should look into Security Token Service or STS.
Check out these links for more information:
Off-the-shelf Security Token Service (STS) that uses ASP.NET membership provider?
http://msdn.microsoft.com/en-us/library/ee517259.aspx
You could have a look here, IdentityModel has Web API support:
http://thinktecture.github.com/Thinktecture.IdentityModel.45/
Summary
Long story short, we've been tasked with gutting the authentication and authorization parts of a fairly old and bloated asp.net application that previously had all of these components written from scratch. Since our application isn't a typical one, and none of us have experience in asp.net's built in membership provider stuff, we're not sure if we should roll our own authentication and authorization again or if we should try to work within the asp.net membership provider mindset and develop our own membership provider.
Our Application
We have a fairly old asp.net application that gets installed at customer locations to service clients on a LAN. Admins create users (users do not sign up) and depending on the install, we may have the software integrated with LDAP.
Currently, the LDAP integration bulk-imports the users to our database and when they login, it authenticates against LDAP so we dont have to manage their passwords. Nothing amazing there.
Admins can assign users to 1 group and they can change the authorization of that group to manage access to various parts of the software.
Groups are maintained by Admins (web based UI) and as said earlier, granted / denied permissions to certain functionality within the application.
All this was completely written from the ground up without using any of the built in .net authorization or authentication. We literally have IsLoggedIn() methods that check for login and redirect to our login page if they aren't.
Our Rewrite
We've been tasked to integrate more tightly with LDAP, they want us to tie groups in our application to groups (or whatever types of containers that LDAP uses) in LDAP so that when a customer opt's to use our LDAP integration, they dont have to manage their users in LDAP AND in our application.
The new way, they will simply create users in LDAP, add them to Groups in LDAP and our application will see that they belong to the appropriate LDAP group and authenticate and authorize them.
In addition, we've been granted the go ahead to completely rip out the User authentication and authorization code and completely re-do it.
Our Problem
The problem is that none of us have any experience with asp.net membership provider functionality. The little bit of exposure I have to it makes me worry that it was not intended to be used for an application such as ours. Though, developing our own ASP.NET Membership Provider and Role Manager sounds like it would be a great experience and most likely the appropriate thing to do.
Basically, I'm looking for advice, should we be using the ASP.NET Membership provider & Role Management API or should we continue to roll our own? I know this decision will be influenced by our requirements so I'm going over them below
Our Requirements
Just a quick n dirty list
Maintain the ability to have a db of users and authenticate them and give admins (only, not users) the ability to CRUD users
Allow the site to integrate with LDAP, when this is chosen, they don't want any users stored in the DB, only the relationship between Groups as they exist in our app / db and the Groups/Containers as they exist in LDAP.
.net 3.5 is being used (mix of asp.net webforms and asp.net mvc)
Has to work in ASP.NET and ASP.NET MVC (shouldn't be a problem I'm guessing)
This can't be user centric, administrators need to be the only ones that CRUD (or import via ldap) users and groups
We have to be able to Auth via LDAP when its configured to do so
I always try to monitor my questions closely so feel free to ask for more info. Also, as a general summary of what I'm looking for in an answer is just. "You should/shouldn't use xyz, here's why".
Links regarding asp.net membership provider and role management stuff are very welcome, most of the stuff I'm finding is 5+ years old.
Security in the context of your problem involves two separate operations: authentication and authorization and those are divided in .NET into MembershipProviders and RoleProviders. I would strongly recommend using both (meaning custom or built-in) to do your authentication and authorization. Doing so, provides a path to upgrade should you later find better tools to do the job and makes it easier for other developers to understand the security.
Now, for authentication, I would, as others have stated, use either the SqlMembershipProvider or the ActiveDirectoryMembershipProvider. My experience has been that in 99% of the cases the ActiveDirectoryMembershipProvider provides enough functionalty for what is need when working against a full AD store (i.e. not ADAM aka ActiveDirectory Application Mode). I have had problems with the ActiveDirectoryMembershipProvider in multi-domain situations but in general finding a way of using it rather than rolling your own is much better. Similarly, the SqlMembershipProvider for authentication, works well and scales well.
Authorization however is an entirely different kettle of fish. This is really where your pain will be felt. First, there is no "ActiveDirectoryRoleProvider". That means if you want to integrate with AD groups, you have three choices:
Use AzMan
Do it yourself via a custom RoleProvider
Find someone that has done it for you.
Use ADFS or Microsoft's new Federated Services
Choice 1: AzMan
AzMan (Authorization Manager) (See also Windows Authorization Manager) is a tool Microsoft wrote to manage application authorization. AzMan has some nice features to it:
It can link your roles to AD groups (or Windows groups)
It can be stored as a file so you can keep it with the application.
Nicely breaks up authorization into tasks, operations and roles.
Comes with a separate administrative tool
The 2008 version will interact with SQL authentication stores.
The catch is that AzMan can be a bear to develop against and understanding the tool is not for someone that isn't experienced. I found that documentation was scant but that was a few years ago. In addition, the AuthorizationStoreRoleProvider does not support Tasks even though AzMan itself does. Tasks are the most granular things that can be done and are group into Operations which themselves can be grouped into Roles into which users or AD groups can be dropped. Documentation has gotten a little better. I do know that when I last worked with AzMan, it's lack of inherit interaction with a database authentication store made it a bit of a pain to work with.
Choice 2: Write your own RoleProvider
This can be a painful experience with LDAP. You would only need a custom RoleProvider in the case where you wanted to query against AD groups and did not want to use AzMan if you planned on using the SqlRoleProvider in non-AD environments.
Another alternative which I have used, is to manage roles in the database and allow the MembershipProvider to be whatever it wants. This still entails writing a custom provider (but a significantly simpler one) and it makes it easy to move the application into an AD environment with little mess. If you store roles in the database and if you want to allow administrators to associate multiple levels of groups to your roles, then you'll have to write that into your custom RoleProvider.
If you plan on using the SqlRoleProvider you also can run into a few issues. If you use the SqlRoleProvider with the SqlMemberProvider in a single application environment then it will work quite well and is very easy to setup. However, if you have multiple applications that you want to authenticate against a single store, then the SqlRoleProvider will not work properly in all cases out of the box without modification.
Choice 3: Find someone that has done it for you.
Specifically, I mean find someone that has developed an ActiveDirectoryRoleProvider. You can easily Google for various choices but I have not used them and would want to pour over any code that anything to do with security in my application.
Choice 4: Active Directory Federated Services
Microsoft has really been pushing this solution which does promise single sign-on if you can get it working. The catch to this solution is getting it setup especially between you and a partner.
I have been very please with the ease of the Membership Provider and Role Provider classes. They just work. The best part in my opinion, is that for my local development, I'm using a SQL Provider to logon to the local database which has the same user names as some of the people I want to test as (Admin, advanced user, basic user) with generic passwords. Then, when I publish my application, it uses the ActiveDirectory Membership Provider and integrates seamlessly. I don't have to change one piece of code for access restrictions. (Except for the differences between my web.config files)
With your situation, it does seem best to write your own custom provider, simply because you want to discover the user in your database but compare their password to LDAP. Also, these seamlessly integrate with both Webforms and MVC.
I would recommend Scott Mitchell's Multipart Series on the providers. Very extensive and thorough.
Also I would add that just because some of the articles are old, doesn't meant they don't still apply. The membership provider framework has been out for a number of years now, so it makes sense that some of the articles are gathering Ethernet dust.
I'm dealing with some of this same stuff so I'm going to start this answer with just a little bit and hopefully build onto it over time.
A quick answer is that, given your requirements, I'm going to suggest that you might want to research the TWO built-in providers that Microsoft makes available to you: SQL Server-based and Active Directory-based. Out of the box, with just the flip of some configuration in your .config file, you can flip the switch from using SQL Server to using Active Directory. Unless I'm misunderstanding your needs, it may sound like this is exactly what you need in your two scenarios. If you do it this way, 100% of your application can look and function identically, even with the same codebase. Migrating data from an existing application of one deployment to the other gets more interesting (and I have no experience with that, unfortunately), but clean deployments of one versus the other should be pretty simple.
Now obviously, if you don't like the behavior of the built-in providers, you can create your own.
Where I am at in my work is that we have been using the SQL-based provider and we need to move to Active Directory and the built-in provider may or may not be sufficient for our needs (I am still evaluating that, and very active in doing so at the moment). I have also worked with some proof-of-concept code so that, in the case that we need to, I have confidence that we can create our own provider reasonably well.
So I know that this is not exactly an answer to your question(s) but I hope that this gives you something to think about for now and helps you in some way. Like I said, I'm happy to add more to this as I grow in knowledge here myself.
FYI material
[How Do I:] Create a Custom Membership Provider? - Video Tutorial from ASP.Net official site. A very nice introduction into the topic.
Simple LDAP Membership Provider - Forum post of a very simple LDAP membership provider.
GPL .Net LDAP Membership Provider - It's GPL, so it may not work for commercial applications. Also hasn't been worked on in a while. But I guess it's still worth mentioning.
Notes
You may have to fight the clients temptation to use LDAP as a database. Be strong! LDAP can be use for Authentication and even Authorization. But you may eventually need to store a lot more information. The only reasonable way to do this is to map your LDAP uid to a database user table and run off that. Your membership provider can make this transparent to the rest of your project. But the client must understand that although LDAP affords them single sign-on, it's shouldn't be used as a database replacement.
Personally, I would stick to the Membership API but try to write a performant backend. Maybe something of a little caching and automatically maps LDAP users to the database user table on the uid as a key. The nice thing about LDAP is it has quite a bit of support in .Net. You won't have to manage sockets, etc. unless you really want to. Due to this, my LDAP/directory access code is usually under a dozen lines per method easily. And that's often good enough for production.
Just to throw another idea into the ring - have you considered Federated authentication and Claims-based authorization? It looks like it may be a good fit for your scenario. Basically this enables you to decouple the authentication from your application into a federated service provider (think OpenID) that manages authentication and issues a token to your application. There are service providers available that will integrate with LDAP, AD, and other directory standards. ADFS (Active Directory Federation Services, formerly Geneva Server) is one example that links with AD.
When configured appropriately, properties that are associated with an identity, such as group membership, can be passed to your application as a "claim" that is associated with the identity - your application can do what it likes with the claim. The point is that your application can find out which groups a user belongs to, and other properties e.g. email address, by examining the claims that are passed within the token.
The advantage of federated authentication is twofold. First, you can integrate with any directory you like, not just LDAP, as long as there is a provider (or of course you can write your own provider). Second, it keeps authentication out of your application code so you can vary the implementation in the future to support different scenarios.
Check out http://msdn.microsoft.com/en-us/magazine/ee335707.aspx for an introduction to the Windows Identity Foundation (formerly code-named 'Geneva Framework'). Or check out the team blog.