Search Results

Search found 73 results on 3 pages for 'adfs'.

facebook twitter digg google delicious technorati stumbleupon myspace wordpress linkedin gmail igoogle windows live tumblr viadeo yahoo buzz yahoo mail yahoo bookmarks favorites email print

Page 1/3 | 1 2 3  | Next Page >

  • WIF, ADFS 2 and WCF–Part 3: ADFS Setup

    - by Your DisplayName here!
    In part 1 of this series I briefly gave an overview of the ADFS / WS-Trust infrastructure. In part 2 we created a basic WCF service that uses ADFS for authentication. This part will walk you through the steps to register the service in ADFS 2. I could provide screenshots for all the wizard pages here – but since this is really easy – I just go through the necessary steps in textual form. Step 1 – Select Data Source Here you can decide if you want to import a federation metadata file that describes the service you want to register. In that case all necessary information is inside the metadata document and you are done. FedUtil (a tool that ships with WIF) can generate such metadata for the most simple cases. Another tool to create metadata can be found here. We choose ‘Manual’ here. Step 2 – Specify Display Name I guess that’s self explaining. Step 3 – Choose Profile Choose ‘ADFS 2 Profile’ here. Step 4 – Configure Certificate Remember that we specified a certificate (or rather a private key) to be used to decrypting incoming tokens in the previous post. Here you specify the corresponding public key that ADFS 2 should use for encrypting the token. Step 5 – Configure URL This page is used to configure WS-Federation and SAML 2.0p support. Since we are using WS-Trust you can leave both boxes unchecked. Step 6 – Configure Identifier Here you specify the identifier (aka the realm, aka the appliesTo) that will be used to request tokens for the service. This value will be used in the token request and is used by ADFS 2 to make a connection to the relying party configuration and claim rules. Step 7 – Configure Issuance Authorization Rules Here you can configure who is allowed to request token for the service. I won’t go into details here how these rules exactly work – that’s for a separate blog post. For now simply use the “Permit all users” option. OK – that’s it. The service is now registered at ADFS 2. In the next part we will finally look at the service client. Stay tuned…

    Read the article

  • ADFS 2.1 proxy trust establishment error

    - by Tommy Jakobsen
    I'm trying to install an ADFS proxy. In our intranet we have a ADFS 2.1 server running on Windows 2012 which is working fine. Now we're trying to deploy a proxy to this one for internet access, using Windows 2012 R2's Web Application Proxy. I'm getting the following error on the proxy server, event ID 393: Message : An error occurred while attempting to establish a trust relationship with the Federation Server. An error occurred when attempting to establish a trust relationship with the federation service. Error: Forbidden Context : DeploymentTask Status : Error I'm not getting any errors on the ADFS server. I've tried with different credentials. The ADFS service account, a domain administrator who is a member of the local administrators group on the ADFs server, and the local administrator account on the ADFS server. Same error message. Both port 80 and 443 is accessible from the proxy server to the internal ADFS server, and I can access the ADFS metadata endpoint from the proxy server. I'm using the same trusted SSL certificate (wildcard) on both machines. Do you have any ideas that can help me troubleshoot this problem?

    Read the article

  • Bind ADFS 2.0 service to a specific IP address

    - by ccellar
    I have one server with ADFS-2.0 and a few websites on it. One of the websites is Dynamics CRM which listens on a specific IP address on port 443. Dynamics CRM provides a metadata file for configuration purposes which could be used to configure a relaying party trust with ADFS. It is accessible with the URL https://auth.contoso.com/FederationMetadata/2007-06/federationmetadata.xml The problem is that ADFS-2.0 installs a service which registers following urlacl https://+:443/FederationMetadata/2007-06/ This means the result of accessing the URL https://auth.contoso.com/FederationMetadata/2007-06/federationmetadata.xml is the metadata file of ADFS, not the one of Dynamics CRM. I've tried to delete the default urlacl and added (one of them at a time) https://192.168.1.2:443/FederationMetadata/2007-06/ https://adfs.mydomain.com:443/FederationMetadata/2007-06/ but neither of them worked. Instead the ADFS-service failed to startup complete. Is there any way to bind this service to a IP address? At the moment I see only two alternatives Bind the service to a non standard port. This leads to problems because this means that also the ADFS website has to use a non-standard HTTPS-port. Install ADFS-2.0 on a different server (this is my favorite alternative - however it is not possible in every situation...)

    Read the article

  • How to install ADFS 3.0 in standalone mode?

    - by user18044
    I've installed Windows 2012 R2 and enabled the ADFS (3.0?) feature. After installation, it asks to configure ADFS, but this step requires a user account that is a domain administrator, as it wants to create certificate containers and SPN records. In ADFS 2.0, you could install in standalone mode which required only local admin rights, storing everything in the Windows Internal Database. If this still possible with the latest version? If so, how do I configure ADFS in standalone mode?

    Read the article

  • ADFS v.2.0 transitive trust in a federation scenario

    - by masi
    Currently i'm working with ADFS to establish a federated trust between two separated domains. My question is simple: does ADFS v. 2.0 support transitive trust across federated identity providers? I know that ADFS v 1.0 does not, as stated in this document on page 9. But when looking on the claims rules that come with ADFS 2.0 it seems to be possible, as a Microsoft partner confirmed. However: the documentation on this topic is a mess! Simply no ADFS v. 2.0 related statements on this topic that i was able to find (IF you got any documentation on this PLEASE help me out guys!). To be more clear, lets assume this scenario: Federation provider (A) trust federation provider (B) which trusts identity provider (C). So, does (A) trust identities comming from (C) across (B)? Also, if it is possible there are some things that i'm specially interested in: Is it possible to restrict the transitive trust in ADFS in any way? If so, how? How does the transitive trust affect the Issuer and OriginalIssuer properties of the claims? If transitive trust is used together with claims transformations and provider (B) would transform incomming claims from (C) in a way that they are transformed into (new) claims of same type an value, how would this affect the Issuer and OriginalIssuer properties?

    Read the article

  • linking Office 365 and ADFS on Azure

    - by Gaurav
    i am trying to link my ADFS to Office 365 in order to set up Single Sign On for Office 365. I am going over this blog post. at Step 5, i am supposed to run Powershell commands so i can connect the ADFS to Office 365. Set-MsolAdfscontext -Computer <AD FS server FQDN> Convert-MsolDomainToFederated -DomainName <domain name> i am unable to determine the FQDN for the ADFS server. i searched around a lot on the web, but was not able to locate the solution. i am just getting started with all configuration of ADFS and Office 365, but was not able to find out a solution. any answers?

    Read the article

  • ADFS 2.0 Server Prompts For Credentials When Using FQDN

    - by ncaudill
    We have an ADFS test enviroment set up, but we are running into issues with login prompts. If we browse to ADFS from Domain A we get a token sucessfully from ADFS, however when we browse from Domain B we are getting prompted for credentials. Domain A trusts Domain B but Domain B does not trust Domain A. The weird thing is, if we replace the full domain name with the server's IP address we can sucessfully get through from both domains. I feel like this should be a really simple solution, but we're stumped.

    Read the article

  • ADFS 2.0 Farm - How do I perform an immediate sync

    - by Matt
    Hi, We're using ADFS 2.0 on a windows 2008 server, it's in a farm and has the default polling interval of 5 minutes. We're making a change tonight and would rather sync immediately than wait for the other guy to update, especially as we might be making multiple changes. This Technet article mentions that I can change the polling interval or do an immediate sync between my servers: http://technet.microsoft.com/en-us/library/ee913581%28WS.10%29.aspx I checked the powershell commandlets for ADFS and I can only seem to find one that let's me set the polling interval, but not perform a 1 time immediate sync Searched the usual suspects, but just can't find a ADFS-SyncMyStuffNow command... Anyone?

    Read the article

  • Server 2012, ADFS 2.1, and Office 365

    - by Matt Bear
    Has anyone gotten ADFS 2.1 on Server 2012 working with o365 SSO? I have it working up to a point, I tweaked the registry to allow the powershell commands to run, user accounts syncs fine. Even the remote connectivity analyzer shows no errors. But SSO itself does not seem to be passing the credentials correctly. Microsoft claims that ADFS 2.1 is not supported to work with o365, but I'm just being stubborn and not giving up that easy.

    Read the article

  • Using ADFS 2.0 for Google apps single sign on

    - by Zoredache
    Microsoft Active Directory Federation Services 2.0 has been recently released, and it has passed interoperability tests for SAML 2.0. Does this mean that is can be used to authenticate users of Google Apps which also uses SAML? Has anyone successfully setup Google apps with ADFS 2.0 for single sign on? If you have gotten it to work please tell us what is required to get this working? To put it another way, does someone have a good HOWTO for using ADFS 2.0 and Google Apps together? I was not able to find anything through a search of the web.

    Read the article

  • Redirect to ADFS login

    - by Patrick
    My company has switched to Office 365 and we like it, but we would really like for the ADFS single sign on to be more simplified. We have to go to login.microsoftonline.com then type in the username, then you have to click the link that appears at the bottom. Then you have to type in your username again and password. So we have come up with the idea that we could just redirect everyone to this page, but after lots of research into this, it seems like it's not possible to do a DNS redirect to a path. Does anyone know any other type of redirect that we could try? I'm thinking about trying to see if I can have a DNS entry go to our TMG and then have the TMG redirect to a path. But I'm not sure how the ADFS server knows where to go after that, so it might just log us in and not go anywhere. Any help will be greatly appreciated.

    Read the article

  • ADFS http login failure not re-requesting credentials

    - by Devnull
    We have ADFS working with HTTP (401) login. If a user types their password incorrectly, ADFS barfs and requires that the browser be closed, rather than asking the user for to attempt to log in again. Reprompting for user credentials is the typical behavior with other web servers (even IIS). This appears to be an artifact of setting the HTTP session, but other HTTP-login applications dont behave this way. We are having additional issues now because some users are saving that password, and its causing them account lockouts because the browsers do not realize they need to update saved credentials. Anyone know of a workaround? Wed rather not enable forms login if possible.

    Read the article

  • WIF, ADFS 2 and WCF&ndash;Part 1: Overview

    - by Your DisplayName here!
    A lot has been written already about passive federation and integration of WIF and ADFS 2 into web apps. The whole active/WS-Trust feature area is much less documented or covered in articles and blogs. Over the next few posts I will try to compile all relevant information about the above topics – but let’s start with an overview. ADFS 2 has a number of endpoints under the /services/trust base address that implement the WS-Trust protocol. They are grouped by the WS-Trust version they support (/13 and /2005), the client credential type (/windows*, /username*, /certificate*) and the security mode (*transport, *mixed and message). You can see the endpoints in the MMC console under the Service/Endpoints page. So in other words, you use one of these endpoints (which exactly depends on your configuration / system setup) to request tokens from ADFS 2. The bindings behind the endpoints are more or less standard WCF bindings, but with SecureConversation (establishSecurityContext) disabled. That means that whenever you need to programmatically talk to these endpoints – you can (easily) create client bindings that are compatible. Another option is to use the special bindings that come with WIF (in the Microsoft.IdentityModel.Protocols.WSTrust.Bindings namespace). They are already pre-configured to be compatible with the ADFS endpoints. The downside of these bindings is, that you can’t use them in configuration. That’s definitely a feature request of mine for the next version of WIF. The next important piece of information is the so called Federation Service Identifier. This is the value that you (at least by default) have to use as a realm/appliesTo whenever you are requesting a token for ADFS (e.g. in  IdP –> RSTS scenario). Or (even more) technically speaking, ADFS 2 checks for this value in the audience URI restriction in SAML tokens. You can get to this value by clicking the “Edit Federation Service Properties” in the MMC when the Service tree-node is selected. OK – I will come back to this basic information in the following posts. Basically I want to go through the following scenarios: ADFS in the IdP role ADFS in the R-STS role (with a chained claims provider) Using the WCF bindings for automatic token issuance Using WSTrustChannelFactory for manual token handling Stay tuned…

    Read the article

  • How to update ADFS 2.0 Proxy Server Certificate?

    - by user167963
    I have proxy server that sits in the DMZ. The default site is running the adfs and has a certificate that is about to expire in 2 weeks. I am not sure what are steps involved in applying a new ssl certificate. I know at the least I will install the new certificate(s) in the local store. Go to IIS and change the certificate using the binding settings. Is there any othern place I have update the certificate?

    Read the article

  • ADFS 2.0 and WebEx

    - by DavisTasar
    We have a brand new deployment going on, where our University has purchased WebEx MeetingPlace. We have the Cisco CallManager component working, but the integration with Single Sign On with ADFS 2.0 has been nothing short of torture. The biggest problem I'm working with is that we use Split-Brain DNS, and our internal domain name versus external domain name is different. Trying to determine what credentials are getting passed back and forth, certificate errors for using the self-signed certificate, etc. Does anyone have any experience with this, or something similar? Do you have any tips, or watch-out-for-this, etc.? I've not worked with a Federated Authentication system before, and this scenario is very black-box-esque. Sorry, I'm also partially ranting as I'm frustrated.

    Read the article

  • ADFS 2.0 and CRM 2011 IFD - Error 403 when being redirected

    - by JohnThePro
    I'm not sure what happened here, but let me give you the rundown. I have a CRM 2011 IFD that by all accounts was functioning. Out of nowhere, I find that when being redirected to ADFS 2.0 login page by CRM, instead of seeing the login page, I get the following error: 403 - Forbidden: Access is denied. You do not have permission to view this directory or page using the credentials that you supplied. I'm not sure what is going on here. The certs are good, as best as I can tell, the logins are good. More specifically, nothing has been modified. This all worked just fine, and now it doesn't. I'm really stumped.

    Read the article

  • WIF, ADFS 2 and WCF&ndash;Part 4: Service Client (using Service Metadata)

    - by Your DisplayName here!
    See parts 1, 2 and 3 first. In this part we will finally build a client for our federated service. There are basically two ways to accomplish this. You can use the WCF built-in tooling to generate client and configuration via the service metadata (aka ‘Add Service Reference’). This requires no WIF on the client side. Another approach would be to use WIF’s WSTrustChannelFactory to manually talk to the ADFS 2 WS-Trust endpoints. This option gives you more flexibility, but is slightly more code to write. You also need WIF on the client which implies that you need to run on a WIF supported operating system – this rules out e.g. Windows XP clients. We’ll start with the metadata way. You simply create a new client project (e.g. a console app) – call ‘Add Service Reference’ and point the dialog to your service endpoint. What will happen then is, that VS will contact your service and read its metadata. Inside there is also a link to the metadata endpoint of ADFS 2. This one will be contacted next to find out which WS-Trust endpoints are available. The end result will be a client side proxy and a configuration file. Let’s first write some code to call the service and then have a closer look at the config file. var proxy = new ServiceClient(); proxy.GetClaims().ForEach(c =>     Console.WriteLine("{0}\n {1}\n  {2} ({3})\n",         c.ClaimType,         c.Value,         c.Issuer,         c.OriginalIssuer)); That’s all. The magic is happening in the configuration file. When you in inspect app.config, you can see the following general configuration hierarchy: <client /> element with service endpoint information federation binding and configuration containing ADFS 2 endpoint 1 (with binding and configuration) ADFS 2 endpoint n (with binding and configuration) (where ADFS 2 endpoint 1…n are the endpoints I talked about in part 1) You will see a number of <issuer /> elements in the binding configuration where simply the first endpoint from the ADFS 2 metadata becomes the default endpoint and all other endpoints and their configuration are commented out. You now need to find the endpoint you want to use (based on trust version, credential type and security mode) and replace that with the default endpoint. That’s it. When you call the WCF proxy, it will inspect configuration, then first contact the selected ADFS 2 endpoint to request a token. This token will then be used to authenticate against the service. In the next post I will show you the more manual approach using the WIF APIs.

    Read the article

  • ADFS Relying Party

    - by user49607
    I'm trying to set up an Active Directory Federation Service Relying Party and I get the following error. I've tried modifying the page to allow <pages validateRequest="false"> to web.config and it doesn't make a difference. Can someone help me out? Server Error in '/test' Application. A potentially dangerous Request.Form value was detected from the client (wresult="<t:RequestSecurityTo..."). Description: Request Validation has detected a potentially dangerous client input value, and processing of the request has been aborted. This value may indicate an attempt to compromise the security of your application, such as a cross-site scripting attack. To allow pages to override application request validation settings, set the requestValidationMode attribute in the httpRuntime configuration section to requestValidationMode="2.0". Example: <httpRuntime requestValidationMode="2.0" />. After setting this value, you can then disable request validation by setting validateRequest="false" in the Page directive or in the <pages> configuration section. However, it is strongly recommended that your application explicitly check all inputs in this case. For more information, see http://go.microsoft.com/fwlink/?LinkId=153133. Exception Details: System.Web.HttpRequestValidationException: A potentially dangerous Request.Form value was detected from the client (wresult="<t:RequestSecurityTo..."). Source Error: An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below. Stack Trace: [HttpRequestValidationException (0x80004005): A potentially dangerous Request.Form value was detected from the client (wresult="<t:RequestSecurityTo...").] System.Web.HttpRequest.ValidateString(String value, String collectionKey, RequestValidationSource requestCollection) +11309476 System.Web.HttpRequest.ValidateNameValueCollection(NameValueCollection nvc, RequestValidationSource requestCollection) +82 System.Web.HttpRequest.get_Form() +186 Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.IsSignInResponse(HttpRequest request) +26 Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.CanReadSignInResponse(HttpRequest request, Boolean onPage) +145 Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args) +108 System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +80 System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +266 `

    Read the article

  • WIF, ADFS 2 and WCF&ndash;Part 2: The Service

    - by Your DisplayName here!
    OK – so let’s first start with a simple WCF service and connect that to ADFS 2 for authentication. The service itself simply echoes back the user’s claims – just so we can make sure it actually works and to see how the ADFS 2 issuance rules emit claims for the service: [ServiceContract(Namespace = "urn:leastprivilege:samples")] public interface IService {     [OperationContract]     List<ViewClaim> GetClaims(); } public class Service : IService {     public List<ViewClaim> GetClaims()     {         var id = Thread.CurrentPrincipal.Identity as IClaimsIdentity;         return (from c in id.Claims                 select new ViewClaim                 {                     ClaimType = c.ClaimType,                     Value = c.Value,                     Issuer = c.Issuer,                     OriginalIssuer = c.OriginalIssuer                 }).ToList();     } } The ViewClaim data contract is simply a DTO that holds the claim information. Next is the WCF configuration – let’s have a look step by step. First I mapped all my http based services to the federation binding. This is achieved by using .NET 4.0’s protocol mapping feature (this can be also done the 3.x way – but in that scenario all services will be federated): <protocolMapping>   <add scheme="http" binding="ws2007FederationHttpBinding" /> </protocolMapping> Next, I provide a standard configuration for the federation binding: <bindings>   <ws2007FederationHttpBinding>     <binding>       <security mode="TransportWithMessageCredential">         <message establishSecurityContext="false">           <issuerMetadata address="https://server/adfs/services/trust/mex" />         </message>       </security>     </binding>   </ws2007FederationHttpBinding> </bindings> This binding points to our ADFS 2 installation metadata endpoint. This is all that is needed for svcutil (aka “Add Service Reference”) to generate the required client configuration. I also chose mixed mode security (SSL + basic message credential) for best performance. This binding also disables session – you can control that via the establishSecurityContext setting on the binding. This has its pros and cons. Something for a separate blog post, I guess. Next, the behavior section adds support for metadata and WIF: <behaviors>   <serviceBehaviors>     <behavior>       <serviceMetadata httpsGetEnabled="true" />       <federatedServiceHostConfiguration />     </behavior>   </serviceBehaviors> </behaviors> The next step is to add the WIF specific configuration (in <microsoft.identityModel />). First we need to specify the key material that we will use to decrypt the incoming tokens. This is optional for web applications but for web services you need to protect the proof key – so this is mandatory (at least for symmetric proof keys, which is the default): <serviceCertificate>   <certificateReference storeLocation="LocalMachine"                         storeName="My"                         x509FindType="FindBySubjectDistinguishedName"                         findValue="CN=Service" /> </serviceCertificate> You also have to specify which incoming tokens you trust. This is accomplished by registering the thumbprint of the signing keys you want to accept. You get this information from the signing certificate configured in ADFS 2: <issuerNameRegistry type="...ConfigurationBasedIssuerNameRegistry">   <trustedIssuers>     <add thumbprint="d1 … db"           name="ADFS" />   </trustedIssuers> </issuerNameRegistry> The last step (promised) is to add the allowed audience URIs to the configuration – WCF clients use (by default – and we’ll come back to this) the endpoint address of the service: <audienceUris>   <add value="https://machine/soapadfs/service.svc" /> </audienceUris> OK – that’s it – now we have a basic WCF service that uses ADFS 2 for authentication. The next step will be to set-up ADFS to issue tokens for this service. Afterwards we can explore various options on how to use this service from a client. Stay tuned… (if you want to have a look at the full source code or peek at the upcoming parts – you can download the complete solution here)

    Read the article

  • Reverse proxy for a REST web service using ADFS/AD and WebApi

    - by Kai Friis
    I need to implement a reverse proxy for a REST webservice behind a firewall. The reverse proxy should authenticate against an enterprise ADFS 2.0 server, preferably using claims in .net 4.5. The clients will be a mix of iOS, Android and web. I’m completely new to this topic; I’ve tried to implement the service as a REST service using WebApi, WIF and the new Identity and Access control in VS 2012, with no luck. I have also tried to look into Brock Allen’s Thinktecture.IdentityModel.45, however then my head was spinning so I didn’t see the difference between it and Windows Identity Foundation with the Identity and Access control. So I think I need to step back and get some advice on how to do this. There are several ways to this, as far as I understand it. In hardware. Set up our Citrix Netscaler as a reverse proxy. I have no idea how to do that, however if it’s a good solution I can always hire someone who knows… Do it in the webserver, like IIS. I haven’t tried it; do not know if it will work. Create a web service to do it. 3.1 Implement it as a SOAP service using WCF. As I understand it ADFS do not support REST so I have to use SOAP. The problem is mobile device do not like SOAP, neither do I… However if it’s the best way, I have to do it. 3.2 Use Azure Access Control Service. It might work, however the timing is not good. Our enterprise is considering several cloud options, and us jumping on the azure wagon on our own might not be the smartest thing to do right now. However if it is the only options, we can do it. I just prefer not to use it right now. Right now I feel there are too many options, and I do not know which one will work. If someone can point me in the right directions, which path to pursue, I would be very grateful.

    Read the article

  • WIF, ADFS 2 and WCF&ndash;Part 5: Service Client (more Flexibility with WSTrustChannelFactory)

    - by Your DisplayName here!
    See the previous posts first. WIF includes an API to manually request tokens from a token service. This gives you more control over the request and more flexibility since you can use your own token caching scheme instead of being bound to the channel object lifetime. The API is straightforward. You first request a token from the STS and then use that token to create a channel to the relying party service. I’d recommend using the WS-Trust bindings that ship with WIF to talk to ADFS 2 – they are pre-configured to match the binding configuration of the ADFS 2 endpoints. The following code requests a token for a WCF service from ADFS 2: private static SecurityToken GetToken() {     // Windows authentication over transport security     var factory = new WSTrustChannelFactory(         new WindowsWSTrustBinding(SecurityMode.Transport),         stsEndpoint);     factory.TrustVersion = TrustVersion.WSTrust13;       var rst = new RequestSecurityToken     {         RequestType = RequestTypes.Issue,         AppliesTo = new EndpointAddress(svcEndpoint),         KeyType = KeyTypes.Symmetric     };       var channel = factory.CreateChannel();     return channel.Issue(rst); } Afterwards, the returned token can be used to create a channel to the service. Again WIF has some helper methods here that make this very easy: private static void CallService(SecurityToken token) {     // create binding and turn off sessions     var binding = new WS2007FederationHttpBinding(         WSFederationHttpSecurityMode.TransportWithMessageCredential);     binding.Security.Message.EstablishSecurityContext = false;       // create factory and enable WIF plumbing     var factory = new ChannelFactory<IService>(binding, new EndpointAddress(svcEndpoint));     factory.ConfigureChannelFactory<IService>();       // turn off CardSpace - we already have the token     factory.Credentials.SupportInteractive = false;       var channel = factory.CreateChannelWithIssuedToken<IService>(token);       channel.GetClaims().ForEach(c =>         Console.WriteLine("{0}\n {1}\n  {2} ({3})\n",             c.ClaimType,             c.Value,             c.Issuer,             c.OriginalIssuer)); } Why is this approach more flexible? Well – some don’t like the configuration voodoo. That’s a valid reason for using the manual approach. You also get more control over the token request itself since you have full control over the RST message that gets send to the STS. One common parameter that you may want to set yourself is the appliesTo value. When you use the automatic token support in the WCF federation binding, the appliesTo is always the physical service address. This means in turn that this address will be used as the audience URI value in the SAML token. Well – this in turn means that when you have an application that consists of multiple services, you always have to configure all physical endpoint URLs in ADFS 2 and in the WIF configuration of the service(s). Having control over the appliesTo allows you to use more symbolic realm names, e.g. the base address or a completely logical name. Since the URL is never de-referenced you have some degree of freedom here. In the next post we will look at the necessary code to request multiple tokens in a call chain. This is a common scenario when you first have to acquire a token from an identity provider and have to send that on to a federation gateway or Resource STS. Stay tuned.

    Read the article

  • WIF, ADFS 2 and WCF&ndash;Part 6: Chaining multiple Token Services

    - by Your DisplayName here!
    See the previous posts first. So far we looked at the (simpler) scenario where a client acquires a token from an identity provider and uses that for authentication against a relying party WCF service. Another common scenario is, that the client first requests a token from an identity provider, and then uses this token to request a new token from a Resource STS or a partner’s federation gateway. This sounds complicated, but is actually very easy to achieve using WIF’s WS-Trust client support. The sequence is like this: Request a token from an identity provider. You use some “bootstrap” credential for that like Windows integrated, UserName or a client certificate. The realm used for this request is the identifier of the Resource STS/federation gateway. Use the resulting token to request a new token from the Resource STS/federation gateway. The realm for this request would be the ultimate service you want to talk to. Use this resulting token to authenticate against the ultimate service. Step 1 is very much the same as the code I have shown in the last post. In the following snippet, I use a client certificate to get a token from my STS: private static SecurityToken GetIdPToken() {     var factory = new WSTrustChannelFactory(         new CertificateWSTrustBinding(SecurityMode.TransportWithMessageCredential,         idpEndpoint);     factory.TrustVersion = TrustVersion.WSTrust13;       factory.Credentials.ClientCertificate.SetCertificate(         StoreLocation.CurrentUser,         StoreName.My,         X509FindType.FindBySubjectDistinguishedName,         "CN=Client");       var rst = new RequestSecurityToken     {         RequestType = RequestTypes.Issue,         AppliesTo = new EndpointAddress(rstsRealm),         KeyType = KeyTypes.Symmetric     };       var channel = factory.CreateChannel();     return channel.Issue(rst); } To use a token to request another token is slightly different. First the IssuedTokenWSTrustBinding is used and second the channel factory extension methods are used to send the identity provider token to the Resource STS: private static SecurityToken GetRSTSToken(SecurityToken idpToken) {     var binding = new IssuedTokenWSTrustBinding();     binding.SecurityMode = SecurityMode.TransportWithMessageCredential;       var factory = new WSTrustChannelFactory(         binding,         rstsEndpoint);     factory.TrustVersion = TrustVersion.WSTrust13;     factory.Credentials.SupportInteractive = false;       var rst = new RequestSecurityToken     {         RequestType = RequestTypes.Issue,         AppliesTo = new EndpointAddress(svcRealm),         KeyType = KeyTypes.Symmetric     };       factory.ConfigureChannelFactory();     var channel = factory.CreateChannelWithIssuedToken(idpToken);     return channel.Issue(rst); } For this particular case I chose an ADFS endpoint for issued token authentication (see part 1 for more background). Calling the service now works exactly like I described in my last post. You may now wonder if the same thing can be also achieved using configuration only – absolutely. But there are some gotchas. First of all the configuration files becomes quite complex. As we discussed in part 4, the bindings must be nested for WCF to unwind the token call-stack. But in this case svcutil cannot resolve the first hop since it cannot use metadata to inspect the identity provider. This binding must be supplied manually. The other issue is around the value for the realm/appliesTo when requesting a token for the R-STS. Using the manual approach you have full control over that parameter and you can simply use the R-STS issuer URI. Using the configuration approach, the exact address of the R-STS endpoint will be used. This means that you may have to register multiple R-STS endpoints in the identity provider. Another issue you will run into is, that ADFS does only accepts its configured issuer URI as a known realm by default. You’d have to manually add more audience URIs for the specific endpoints using the ADFS Powershell commandlets. I prefer the “manual” approach. That’s it. Hope this is useful information.

    Read the article

  • Creating custom IP-STS for sharepoint foundation 2010 without ADFS

    - by user252229
    I plan to create very simple custom IP-STS for SharePoint foundation 2010 without ADFS server so anyone can integrate Windows Live ID to SharePoint foundation 2010 simply without ADFS, I can't use ADFS server because it could not install on Windows Web Server 2008 (Web Edition), also I found many article use LDAP provider but it does not exists in SharePoint Foundation too (it requires Sharepoint Server Edition). After too much searching I just found the following article and find all technique except one problem. 1) Creating Custom Claim Provider: blogs.technet.com/b/speschka/archive/2010/03/13/writing-a-custom-claims-provider-for-sharepoint-2010-part-1.aspx 2) Creating Custom STS Provider: http://blogs.msdn.com/b/chunliu/archive/2010/04/02/how-to-make-use-of-a-custom-ip-sts-with-sharepoint-2010-part-1.aspx Only one step remains: I got following error after enter username in STS site and redirect to localhost/_trust/default.aspx , ( I leave EncryptingCertificateName empty). Operation is not valid due to the current state of the object I expect to get access denied error instead of that error. 1.Is it possible anyway? 2.Can anyone help me where can I find working article to create custom IP-STS without ADFS server Any idea will help me Thanks

    Read the article

facebook twitter digg google delicious technorati stumbleupon myspace wordpress linkedin gmail igoogle windows live tumblr viadeo yahoo buzz yahoo mail yahoo bookmarks favorites email print

1 2 3  | Next Page >