How to set up AD FS for a development machine
In this article I will describe how you should set up a development computer to use an existing AD FS.
First thing we need to do is to create a trust between the ADFS server and the development machine. You can do this by login in with RDP at the server that is running ADFS and start up the "AD FS 2.0 Management" that is found under the Administrative tools. When the AD FS 2.0 Management studio is started you need to navigate to the "Relying Party Trusts" in the left folder structure. Then you nee to select "Add Relying Party Trust..." in the right menu.
This will open the "Add Relying Party Trust Wizard" as shown below.
When clicked on "Start" the following screen will open. Here you can specify how the relying party configuration is configured. For a development machine it is most easy to select just the last option "Enter data about the relying party manually"
In the next screen you can fill in a name and description. This is really only important to recognise the relying party between others. You can specify here the machine name but could also use the name of the user that owns the machine.
In next screen you can specify an optional certificate to encrypt the claim token with. This is not needed for a development environment and therefore we leave it blank.
In the next screen you can add some optional extra protocol options. We do not need these for development but I can imagine that some development environments need these options. Then select them but just leave them unchecked for the default behaviour.
Next is an important step. In this step you need to specify where the ADFS service needs to redirect back to. When a user is validated on the ADFS website the claims that belong to the current user need to be send back to the website where the login originated from. The website where the claim requests starts from (and needs to be redirect back to) is specified here below. Do not use localhost in this URL, this can not be recognised. Just use your machine name and if the app is in the sub directory then specify this address in the "Relying party trust identifier:" and click Add.
Next step is to set the default policy for redirecting, you can specify that the default settings is that all users are denied (opt in) or all users are permitted. For a development environment probably "Permit all users to access this relying party" is the best solution.
Next step looks scary but is really a summarized overview. Not really interesting if you ask me. Just click next.
And the Finish screen. If you select the "Open the Edit Claim Rules..." after saving the Relying Party Trust a configuration screen opens where you can specify for instance extra claims that are send to the relying party. If you for instance want to sent extra roles within the claim then this screen is handy (standard is that nothing is send). This topic of configuration I will maybe describe in a following blog but not now.
That's all folks!
Or not? You of course also need to configure the client side. If you are the first in the project that need to configure the connection to the server then my advise is to first install de Windows Identity Foundation SDK that you can download on http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=4451 .
Within this SDK there is a very handy Visual Studio plug in that helps configure your AD FS connection in the web.config or app.config. I will not handle this for now. Maybe in a later blog when I face this problem again.
ID1032: At least one 'audienceUri' must be specified in the SamlSecurityTokenRequirement when the AudienceUriMode is set to 'Always' or 'BearerKeyOnly'. Either add the valid URI values to the AudienceUris property of SamlSecurityTokenRequirement, or turn off checking by specifying an AudienceUriMode of 'Never' on the SamlSecurityTokenRequirement.
Solution: Within the web.config of the website an section called audienceUri exists. Within this section there should be values that correspond to the identifiers configured on the adfs server (step "Configure identifiers". Check that these values correspond. Here below an example
<microsoft.identityModel>
<service>
<audienceUris>
<add value="https://laptop-04/CompanyWebsite" />
<add value="http://laptop-04/CompanyWebsite" />
etc..
MSIS7007: The requested relying party trust 'http://laptop-04/CompanyWebsite/' is unspecified or unsupported. If a relying party trust was specified, it is possible that you do not have permission to access the trust relying party. Contact your administrator for details.
Solution: You did not add the correct identifier in "Configure identifiers" you can add the identifier specified here above to the ADFS configuration on the server or change the identifier within the web.config of the calling application (see the wsFederation element attribute realm).
ID4175: The issuer of the security token was not recognized by the IssuerNameRegistry. To accept security tokens from this issuer, configure the IssuerNameRegistry to return a valid name for this issuer.
Within the web.config on the receiving side (your developers website) there is a thumprint stored. If the certificate used for signing is changed then also you need to change the thumbprint within this file. Be aware that the tumbprint should be upper case otherwise it will not work. See the element
First thing we need to do is to create a trust between the ADFS server and the development machine. You can do this by login in with RDP at the server that is running ADFS and start up the "AD FS 2.0 Management" that is found under the Administrative tools. When the AD FS 2.0 Management studio is started you need to navigate to the "Relying Party Trusts" in the left folder structure. Then you nee to select "Add Relying Party Trust..." in the right menu.
This will open the "Add Relying Party Trust Wizard" as shown below.
When clicked on "Start" the following screen will open. Here you can specify how the relying party configuration is configured. For a development machine it is most easy to select just the last option "Enter data about the relying party manually"
In the next screen you can fill in a name and description. This is really only important to recognise the relying party between others. You can specify here the machine name but could also use the name of the user that owns the machine.
In the next screen you can specify which version of AD FS is used. For development this is probably the newest version so we choose this one.
In next screen you can specify an optional certificate to encrypt the claim token with. This is not needed for a development environment and therefore we leave it blank.
In the next screen you can add some optional extra protocol options. We do not need these for development but I can imagine that some development environments need these options. Then select them but just leave them unchecked for the default behaviour.
Next is an important step. In this step you need to specify where the ADFS service needs to redirect back to. When a user is validated on the ADFS website the claims that belong to the current user need to be send back to the website where the login originated from. The website where the claim requests starts from (and needs to be redirect back to) is specified here below. Do not use localhost in this URL, this can not be recognised. Just use your machine name and if the app is in the sub directory then specify this address in the "Relying party trust identifier:" and click Add.
Next step is to set the default policy for redirecting, you can specify that the default settings is that all users are denied (opt in) or all users are permitted. For a development environment probably "Permit all users to access this relying party" is the best solution.
Next step looks scary but is really a summarized overview. Not really interesting if you ask me. Just click next.
And the Finish screen. If you select the "Open the Edit Claim Rules..." after saving the Relying Party Trust a configuration screen opens where you can specify for instance extra claims that are send to the relying party. If you for instance want to sent extra roles within the claim then this screen is handy (standard is that nothing is send). This topic of configuration I will maybe describe in a following blog but not now.
That's all folks!
Or not? You of course also need to configure the client side. If you are the first in the project that need to configure the connection to the server then my advise is to first install de Windows Identity Foundation SDK that you can download on http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=4451 .
Within this SDK there is a very handy Visual Studio plug in that helps configure your AD FS connection in the web.config or app.config. I will not handle this for now. Maybe in a later blog when I face this problem again.
Errors that you can encounter
Sometimes it however happens that you encounter an error, here below I describe the errors that I sometimes face and what there solutions are.ID1032: At least one 'audienceUri' must be specified in the SamlSecurityTokenRequirement when the AudienceUriMode is set to 'Always' or 'BearerKeyOnly'. Either add the valid URI values to the AudienceUris property of SamlSecurityTokenRequirement, or turn off checking by specifying an AudienceUriMode of 'Never' on the SamlSecurityTokenRequirement.
Solution: Within the web.config of the website an section called audienceUri exists. Within this section there should be values that correspond to the identifiers configured on the adfs server (step "Configure identifiers". Check that these values correspond. Here below an example
<microsoft.identityModel>
<service>
<audienceUris>
<add value="https://laptop-04/CompanyWebsite" />
<add value="http://laptop-04/CompanyWebsite" />
etc..
MSIS7007: The requested relying party trust 'http://laptop-04/CompanyWebsite/' is unspecified or unsupported. If a relying party trust was specified, it is possible that you do not have permission to access the trust relying party. Contact your administrator for details.
Solution: You did not add the correct identifier in "Configure identifiers" you can add the identifier specified here above to the ADFS configuration on the server or change the identifier within the web.config of the calling application (see the wsFederation element attribute realm).
ID4175: The issuer of the security token was not recognized by the IssuerNameRegistry. To accept security tokens from this issuer, configure the IssuerNameRegistry to return a valid name for this issuer.
Within the web.config on the receiving side (your developers website) there is a thumprint stored. If the certificate used for signing is changed then also you need to change the thumbprint within this file. Be aware that the tumbprint should be upper case otherwise it will not work. See the
Comments