Re: ADFS and authorization

On May 23, 11:26 am, "Joe Kaplan"
<joseph.e.kap...@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
That's basically it. To restate a little:

It is basically the responsibility of the application to provide
authorization. Some things will be rejected by the federation server such
as a ticket from an unknown partner, a ticket with a bad signature or a
ticket with a skewed date time (make sure your clocks are in sync!).
However, if your app needs a ticket with a specific claim, the app needs to
check for that.

As previously stated, there are two integration styles, claims-aware and NT
token. NT token is for backwards compatibility as it integrates directly
with IIS. Claims-aware apps integrate at the .NET layer in ASP.NET and
require .NET 2.0. Token apps are a bit of a pain to deal with as the
mapping of federation users to Windows tokens can be painful. I suggest
avoiding it if possible. However, if you use this style, the integration is
just like with any other web app that uses Windows security in that you are
authorizing based on a Windows security token that contains a user and group
SIDs.

For claims aware apps, there are a few different ways to do this, depending
on the abstraction layer you prefer:
- Raw claims (just access the properties of the SingleSignOnIdentity and
implement logic based on that)
- .NET IPrincipal.IsInRole (group claims are mapped to IPrincipal roles)
- ASP.NET 2.0 Membership/Role provider framework
- AzMan

Raw claims gives you the most power, but couples you directly to the ADFS
.NET types, so it is the least flexible. For example, you wouldn't have an
easy way to test this on an XP-based development workstation as you can't
get ADFS installed or executing on XP. I created a package that will allow
you to compile apps that use the ADFS types on XP using VS.NET, but they
still won't execute.

I tend to like abstraction layers at this level of my web apps as they
provide flexibility and make testing easier. However, you lose some power,
mostly with the custom claims data, as that doesn't tend to be represented
well by AzMan, Membership or IsRole. Those frameworks tend to work mostly
with group claims. However, membership is very attractive because there are
so many other options for authn/authz with the membership framework (SQL,
AD, custom, etc.). This is also what MOSS 2007 uses as its integration
point.

I like AzMan, but I tend to avoid it unless I need a more powerful
authorization framework that can benefit from the additional abstraction.

I hope that helps provide some additional ideas.

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"http://www.directoryprogramming.net
--"Tomasz Onyszko" <T.onyszko_nosp...@xxxxxx> wrote in message

news:Ob9gxuTnHHA.3544@xxxxxxxxxxxxxxxxxxxxxxx

dasmay wrote:
If I design an app that uses ADFS claims based authentication is there
something in ADFS that controls who can access my app or is it up to
my application to provide/handle the authorization? We have just
implemented ADFS in our new internet environment and I'm developing an
Asp.net 2.0 app and trying to determine what is best way to use ADFS.
If I understand correctly ADFS does have Windows NT Token based apps
but this seemed better suited for legacy asp app or something like
Share point sites. My site will need to control who can access and
once you have access there are certain users who need access to
administration pages.

I'm not ASP .NET developer and probably Joe Kaplan will jump in this
thread ... in ASP .NET You have to utilize claims which are provided in
ADFS token and make Your authorization decision based on this information.
Claim-aware application which is provided as a sample in step by step
document shows how to do this using IsInRole if I remeber correctly.

Infromation on claim aware applications from technet:
http://technet2.microsoft.com/windowsserver/en/library/cb6ab1be-5af6-...

--
Tomasz Onyszko
http://www.w2k.pl/- (PL)
http://blogs.dirteam.com/blogs/tomek/- (EN)



Thanks Joe for explaination and yes this sense. I found your blog
entry on creating a package for dev machine to get the dlls needed for
ADFS to compile in VS2005

.

Relevant Pages

  • Re: ADFS June 2006 Step-by-step guide
    ... Under ADFS, the app needs to be set to anonymous ... Co-author of "The .NET Developer's Guide to Directory Services Programming" ...
    (microsoft.public.windows.server.active_directory)
  • Re: ADFS June 2006 Step-by-step guide
    ... alansh@xxxxxxxxxx in the resource forest. ... ADFS to map to a specific user in your forest or if you want a token based ... The claims app will help you debug all this stuff and the quick start sample ... Co-author of "The .NET Developer's Guide to Directory Services Programming" ...
    (microsoft.public.windows.server.active_directory)
  • Re: ADFS - SAML audience
    ... When you log into an app ... into a different ADFS app, it will redirect you back to the FS. ... case, since you have a logon cookie from the FS, you SSO into the FS and it ... If you were doing a pure "inside the firewall" web SSO with a set of web ...
    (microsoft.public.windows.server.active_directory)
  • Re: ADFS with ASP application
    ... incoming group claim to user on resource computer .Is it correct? ... able to bypass ADFS to get into the application. ... It is generally much easier to troubleshoot this with a claims app first ... map user tokens. ...
    (microsoft.public.windows.server.active_directory)
  • Re: Permit only one network logon per user
    ... authorization on in your app. ... allow a second connection to it using the same creds. ... If user username try to login from a different machine, ...
    (microsoft.public.windows.server.security)