Re: ADFS - SAML audience

Ok, let me clarify my point a bit.
Microsoft's ADFS Overview document describes three scenarios for using ADFS,
one of them is the "Web SSO" scenario. In this scenario, they suggest that
the FSP is multihomed between internal and DMZ, as well as web/app servers,
and FS is inside the internal network. And they suggest that this usage
scenario provides the Web SSO, by having the user log in only once to access
all of these web/apps.
Now, since I don't have that setup and can't test it, my question is, what
is the value of SAML:audience that the user gets from that FS when accessing
those web apps? If the value is equal to the URL for the web app being
accessed then Web SSO doesn't work, if it's the value of the FS URN then it
does. Since Microsoft says this setup works for SSO, then I assume the issued
SAML:audience is equal to the FS URN, but then this is in contrast to what my
tests have showed when accessing the web app without the FSP, with only one
FS.
Am I misinterpreting something? My original message on this thread was
whether the resource FS can issue the SAML token with SAML:audience pointing
to itself? This was because I couldn't explain how otherwise this Web SSO
scenario Microsoft describes in their ADFS Overview doc could work.


"Joe Kaplan" wrote:

I guess I'm not totally following what you are saying. I've actually based
my knowledge primarily on my own experiences with testing and deploying ADFS
and less on the Microsoft documentation, so I wasn't totally familiar with
their overview doc.

However, I don't see why the web SSO scenario can't work with either
token-based or claims-based apps. That is largely an implementation
decision for the application, but shouldn't really matter for the app's URL.
Token-based integration gives you more compatibility, as it can basically
integrate with anything that runs on IIS and can consume Windows security,
so it can be used with older .NET, ASP or perhaps even PHP and Java if you
run that on Windows. Claims integration is much more flexible, but does
require .NET 2.0 for the app and may require code changes that might not be
needed in a token app integration. There are some abstraction layers
implemented by ADFS such as the support for the standard .NET IPrincipal
object, the membership provider/role provider integration and their AzMan
integration.

Can you provide some specific examples that I can digest in regards to your
concerns about audience and multi-homing and such? From my perspective,
multi-homed web servers are par for the course, as we do so much stuff with
SSL internally and dealing with host headers with SSL is often problematic
or even possible. Giving every website their own IP just makes things
easier. We also use SSL on everything though, so that is probably a big
difference thing for our internal IT and many other companies.

Our primary use case (so far) for ADFS has been external federation and
integration with vendor apps hosted in the ASP model. We already have web
SSO internally with another product (although ADFS does provide a possible
avenue toward consolidation of strategies at some point in the future...).

I don't think that response was particularly helpful to you, but I'm
enjoying the conversation anyway. :)

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
--
"Dima" <Dima@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:A43164AA-82FE-41BA-8EE1-9CDC95935D1A@xxxxxxxxxxxxxxxx
By Web SSO, are you referring to the usage scenario described in the ADFS
Overview document? If so, I have a few comments:

This scenario assumes that those servers are multihomed, which is rarely
the
case in companies that have a perimeter network.
I must admit, that usage scenario description in the ADFS Overview doc is
somewhat unclear to me. Does it only work with Windows token-based apps?
Or
does it work for any kind of authentication and account store?
If the resource FS issues a SAML token with the aufdience set to the URL
of
the application then SSO isn't possible, so for the Web SSO scenario to
work
the FS would have to issue some other audience value, right?
Please be as detailed as possible.


"Joe Kaplan" wrote:

The SAML tokens are different here. The token issued to the FS basically
logs the user into the FS. The FS then generates a different token that
is
sent to the trusting application. This is part of the way that different
apps can be configured to have different claim sets. They would have to
get
their own token in order for that to work.

However, Web SSO should be possible with just one server. My previous
comments to you about putting the ADAM store in its own FS will give you
a
bunch of additional flexibility with applications that need to integrate
via
Windows token, but if you don't have any of those, then it won't be a
problem.

If you want me to explain the finer points on the token integration
stuff, I
can. I won't dive into unless it is important to hear about.

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
--
"Dima" <Dima@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:6A34E913-001B-403D-AE39-55C5D7E1A8E6@xxxxxxxxxxxxxxxx
I have a question about the <saml:Audience> tag in the SAML token.
After examining the SAML token in the ADFS log, I saw that the resource
FS
generated SAML token contiains the audience value set to the URL of the
application being accessed (return URL). On the other hand, the SAML
token
generated by the account FS has the audience value set to the URI of
the
resource FS (urn:federation:treyresearch). This resource FS URN
audience
is
required in order for the SSO to work. Is there any way that the
resource
FS
would generate the FS URN audience instead of the application URL? Can
I
set
it up to be it's own account partner? I know it sounds weird, but all I
really want is to have true SSO with only one server (resource FS).







.

Relevant Pages

  • Re: ADFS and Web SSO Scenario
    ... The thing to remember with the Web SSO scenario is that it is conceptually ... claims apps using just the federation server and IWA. ...
    (microsoft.public.windows.server.active_directory)
  • Re: Questions on a perimeter network.
    ... We do plan on rolling out ADFS in the future. ... The scenario that you are following is the model scenario for the ... Microsoft Federation Services deployment guide. ...
    (microsoft.public.win2000.active_directory)