ADFS supports three types of claims: identity claims, group claims, and custom claims. With respect to identity claims, three types of identifiers are supported: User Principal Name (UPN), Email Name, and Common Name.
For a given account partner, only one type of identifier can be enabled. The Email Identity Claim has an interesting limitation in that you must confine the mapping to specific email domain suffixes. UPN has a similar limitation, but this is less onerous because the account partner typically has control over the UPN suffix. So UPN is typically the primary identity claim.
How should email addresses be handled when UPN is used as the identity claim? The documentation suggests that they be treated as simple custom claims. With some effort, however, it is possible to treat email as a second identity claim - at least by the time it reaches the resource - without defining specific domain suffixes. Here's how:
The basic technique is to take advantage of the fact that ADFS converts any custom claim with the name 'EmailAddress' to an email claim. The conversion routine actually occurs twice: once when incoming claims are mapped to organization claims ("pre-transform stage"), and again when organization claims are mapped to outgoing or resource claims ("post-transform stage"). The effect is that if the account partner provides a custom claim with the name 'EmailAddress' then the 'pre' conversion - with email filter - will be applied. To avoid the filter, the account partner must provide a custom claim with a name other than 'EmailAddress'. Map that claim to an organization claim with the name 'EmailAddress', and the 'post-transform' conversion will instead take place with no filter. Voila, your claims-enabled application will see an 'EmailName' identity claim!
Guess what? This technique breaks when you use transform modules. ADFS will report an error to the effect of: "Argument 'name' cannot equal EmailAddress if type equals WebSsoClaimType.Custom". The fix unfortunately impacts your account partners: the partner must provide the email as a true email identity claim ('EmailAddress'), and your transform module must manually propagate the claim from the incoming collection to the corporate collection. You can then enable the 'E-mail' identity claim for applications that should receive the email address.
Hope this helps!
Tools 
Help
