Re: Active Directory Federated Services Custom Claim Transforms

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

In order for me to provide a more useful reply, I'm going to have to play
around a bit tomorrow with our lab. Please be patient and I'll try to reply
tomorrow afternoon.

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
--
"Q" <Q@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:5C8894FF-5E3C-4D8F-A2C3-5C9B524CF9B7@xxxxxxxxxxxxxxxx
Well I looked at the FederatedServerService code and I am a little
disturbed
by what it shows. In the code below that shows the call for the custom
transform in preprocessing and post processing it shows that this happens:

Call Custom Transform Preprocessing
if (trustPolicy.CustomTransformation != null)
{
trustPolicy.CustomTransformation.TransformClaims(true, issuerUri,
trustingRealm, ref inClaims, ref corpClaims, ref outClaims);
}

After that it uses inclaims and adds to corpClaim with it:
realm.ClaimTransformation.TransformClaims(inClaims, corpClaims);

The it uses corpClaims and adds to outClaims:
trustingRealm.ClaimTransformation.TransformClaims(corpClaims, outClaims);

This means if you change corpClaim or outClaim in Preprocessing it will
get
overwritten in the steps above that occur after preprocessing. The key
thing
here is that you logically could get around this by changing the inClaim
but
this doesn't seem to be allowed because you end up throwning a
InvalidOperationException . "Collection was modified"
So it doesn't allow inclaim to be modified.

A similiar thing occurs after PostProcessing...

PostProcessing occurs:
trustPolicy.CustomTransformation.TransformClaims(false, issuerUri,
trustingRealm, ref inClaims, ref corpClaims, ref outClaims);

After Postprocessing the corpClaim is modified using inClaim so any
changes
I would put here would be overwritten:
corpClaims.UserSamName = inClaims.UserSamName;
corpClaims.UserSid = inClaims.UserSid;
corpClaims.PackedSids = inClaims.PackedSids;

Futher code shows that after this outClaim is changed using corpClaim and
since any changes I make don't go to UserSamName, UserSid, & PacketSids
hince
it would not be able to get my user's proper security token for access.


If somehow I misunderstood or there is a way around this let me know. I
hope this isn't the case.

private void TransformClaims(TrustPolicy trustPolicy, ClaimContext
inClaims,
TrustingRealm trustingRealm, out ClaimContext corpClaims, out ClaimContext
outClaims)
{
outClaims = new ClaimContext();
outClaims.ClaimIssuer = trustPolicy.TrustedSelf;
outClaims.ClaimAcceptor = trustingRealm;
TrustedRealm realm = inClaims.ClaimIssuer as TrustedRealm;
AccountStore store = inClaims.ClaimIssuer as AccountStore;
if ((realm == null) || realm.IsSelf)
{
corpClaims = inClaims;
inClaims = null;
}
else
{
corpClaims = new ClaimContext();
corpClaims.ClaimIssuer = trustPolicy.TrustedSelf;
corpClaims.ClaimAcceptor = trustPolicy.TrustingSelf;
}
string issuerUri = null;
if (realm != null)
{
issuerUri = realm.TrustPolicyEntryUri;
}
else if (store != null)
{
issuerUri = store.TrustPolicyEntryUri;
}
if (trustPolicy.CustomTransformation != null)
{
trustPolicy.CustomTransformation.TransformClaims(true, issuerUri,
trustingRealm, ref inClaims, ref corpClaims, ref outClaims);
}
if (inClaims != null)
{
realm.ClaimTransformation.TransformClaims(inClaims, corpClaims);
}
if ((trustingRealm != null) && !trustingRealm.IsSelf)
{
trustingRealm.ClaimTransformation.TransformClaims(corpClaims,
outClaims);
}
if (trustPolicy.CustomTransformation != null)
{
trustPolicy.CustomTransformation.TransformClaims(false, issuerUri,
trustingRealm, ref inClaims, ref corpClaims, ref outClaims);
}
if (inClaims != null)
{
corpClaims.UserSamName = inClaims.UserSamName;
corpClaims.UserSid = inClaims.UserSid;
corpClaims.PackedSids = inClaims.PackedSids;
}

There was more code but I figured you had this already and could refer to.

Q

"Joe Kaplan" wrote:

The claims that you modify during the processing step are still signed by
the federation server before the SAML token is serialized and sent to the
next federation server or application, so the token should be technically
valid. I'd like to understand in more detail the behavior you are
gettign
when the logon fails. Can you provide some exception details and debug
log
trace of the failure?

The pre-processing vs. post-processing thing is really just intended to
give
you a crack at the claims either before or after the built in
mappings/transforms take place. The built in stuff is just whatever you
have defined in your trust policy for the app or outbound federation
server
that will receive the token and can be things like UPN transformations or
claim name remapping. This is basically what is leading me to conclude
that
there is something else going wrong after you do post processing.

If you are curious, I highly recommend getting .NET Reflector to reverse
engineer the source code and look inside the TransformClaims method of
the
FederationServerService class. Given than the SDK docs have some
catching
up to do, this is by far the most useful way to learn how all of ADFS
actually works. ADFS is written in almost all managed code (they have a
few
things in C++ that can't be reverse engineered with Reflector), so this
is
actually fairly practical.

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
--
"Q" <Q@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:3C7233AF-3C9E-471F-ABC9-8DDA0339AC7D@xxxxxxxxxxxxxxxx
Isn't Postprocessing where the Security Token is created? When I do a
change
in PostProcessing it seems that the Security Token is already changed
before
my change because when looking at the Web App end it shows the UPN
change
but
logon fails as if the security Token is incorrect. So I need to insure
it
changes before any Security Token is created. So if I am thinking
wrong ,
sure let me know, but I know my attempts to have failed in
Postprocessing
"outgoingClaim". MSDN docs and R2 SDK (see below) state that Corporate
Claim
is what gets transformed into Outgoing Claim which creates security
token
during processing. 'Post' processing would lead me to believe
Postprocessing is after this step of security token creation.


"corporateClaims
The corporate claims collection used in claim processing. For more
information about claims processing, see the Remarks section.

This collection represents claims normalized to corporate claims. At
the
end
of processing, this collection is sometimes used to generate an
accelerator
token used by the client for subsequent requests.

outgoingClaims
The outgoing claims collection used in claim processing. For more
information about claims processing, see the Remarks section.

This collection represents claims transformed and/or filtered
appropriately
for the target. At the end of processing, this collection is used to
generate
the security token for the target.

"

above came from
http://msdn2.microsoft.com/en-us/library/system.web.security.singlesignon.iclaimtransform.transformclaims.aspx


"Joe Kaplan" wrote:






.

Relevant Pages

  • Re: Active Directory Federated Services Custom Claim Transforms
    ... trustingRealm, ref inClaims, ref corpClaims, ref outClaims); ... After that it uses inclaims and adds to corpClaim with it: ... realm.ClaimTransformation.TransformClaims(inClaims, corpClaims); ... The it uses corpClaims and adds to outClaims: ...
    (microsoft.public.windows.server.active_directory)
  • Re: Active Directory Federated Services Custom Claim Transforms
    ... trustingRealm, ref inClaims, ref corpClaims, ref outClaims); ... After that it uses inclaims and adds to corpClaim with it: ... realm.ClaimTransformation.TransformClaims(inClaims, corpClaims); ... The it uses corpClaims and adds to outClaims: ...
    (microsoft.public.windows.server.active_directory)