none
Problem authenticating to ADFS with username and password RRS feed

  • Question

  • I build a web service that will take username/password and based on these credentials authenticate users (mobile apps) in ADFS2. My web service is configured as RP on the ADFS. ADFS issues SAML 2.0 tokens.

    Here is a code of the web method:

        public class MobileAuthService : IMobileAuthService
        {
            private const string adfsBaseAddress = @"https://<my_ADFS_hostname>/adfs/services";
            private const string endpointSuffix = @"/trust/13/usernamemixed";
    
            private const string relyingPartyAddress =
                "https://<my_WCF_service_address>/Auth.svc";
    
            public string AuthenticateUser(string username, string password)
            {
                var binding = new UserNameWSTrustBinding(SecurityMode.TransportWithMessageCredential)
                    {
                        ClientCredentialType = HttpClientCredentialType.None
                    };
    
                var trustChannelFactory = new WSTrustChannelFactory(binding, new EndpointAddress(adfsBaseAddress + endpointSuffix))
                                                {
                                                    TrustVersion = TrustVersion.WSTrust13
                                                };
                trustChannelFactory.Credentials.UserName.UserName = username;
                trustChannelFactory.Credentials.UserName.Password = password;
    
                var tokenClient = (WSTrustChannel)trustChannelFactory.CreateChannel();
    
                var rst = new RequestSecurityToken(RequestTypes.Issue, KeyTypes.Symmetric)
                    {
                        AppliesTo = new EndpointReference(relyingPartyAddress)
                    };
                var token = tokenClient.Issue(rst);
    			
    			// do some token-related stuff
    			
                return token.Id;
            }
        }

    I'm getting the following error:

    System.ServiceModel.FaultException - ID3242: The security token could not be authenticated or authorized.

    In WCF traces I've found the following messages:

    System.ServiceModel.Security.MessageSecurityException
    
    Security processor was unable to find a security header in the message. This might be because the message is an unsecured fault or because there is a binding mismatch between the communicating parties.   This can occur if the service is configured for security and the client is not using security.
    <E2ETraceEvent xmlns="http://schemas.microsoft.com/2004/06/E2ETraceEvent">
    	<System xmlns="http://schemas.microsoft.com/2004/06/windows/eventlog/system">
    		<EventID>458802</EventID>
    		<Type>3</Type>
    		<SubType Name="Warning">0</SubType>
    		<Level>4</Level>
    		<TimeCreated SystemTime="2013-10-11T12:03:12.1592311Z" />
    		<Source Name="System.ServiceModel" />
    		<Correlation ActivityID="{e32b52a6-64e0-40d2-a0b1-2c2f91c1ad78}" />
    		<Execution ProcessName="w3wp" ProcessID="12352" ThreadID="70" />
    		<Channel />
    		<Computer>PLKRK-L-R824Y1R</Computer>
    	</System>
    	<ApplicationData>
    		<TraceData>
    			<DataItem>
    				<TraceRecord xmlns="http://schemas.microsoft.com/2004/10/E2ETraceEvent/TraceRecord" Severity="Warning">
    					<TraceIdentifier>http://msdn.microsoft.com/en-US/library/System.ServiceModel.Security.SecurityBindingVerifyIncomingMessageFailure.aspx</TraceIdentifier>
    					<Description>The security protocol cannot verify the incoming message.</Description>
    					<AppDomain>/LM/W3SVC/1/ROOT/xxx.Mobile.Auth.Service-2-130259665857285881</AppDomain>
    					<ExtendedData xmlns="http://schemas.microsoft.com/2006/08/ServiceModel/SecurityProtocolTraceRecord">
    						<SecurityProtocol>System.ServiceModel.Security.TransportSecurityProtocol</SecurityProtocol>
    						<Action>http://www.w3.org/2005/08/addressing/soap/fault</Action>
    					</ExtendedData>
    				</TraceRecord>
    			</DataItem>
    		</TraceData>
    	</ApplicationData>
    </E2ETraceEvent>

    Any idea what may be the cause of this problem?

    The ADFS server certificate is fine - at least my browser accepts it as a valid.


    Friday, October 11, 2013 1:01 PM

All replies

  • Hi,
    >>Security processor was unable to find a security header in the message. This might be because the message is an unsecured fault or because there is a binding mismatch between the communicating parties.   This can occur if the service is configured for security and the client is not using security.

    First of all, please make sure Bindings are matched in the client and service, the security settings of the binding are same. As mentioned in the error message, the error can occur when the service is configured for a security and the client is not using security.

    For the Authenticate user by using ADFS, please try to check the following:
    #Authenticate username and password against remote ADFS 2.0:
    http://believeinmiraclesx.wordpress.com/2013/09/06/authenticate-username-and-password-against-remote-adfs-2-0/ .
    #Authenticate user by ADFS:
    http://stackoverflow.com/questions/7819473/implementing-acs-with-and-adfs-as-sts .

    >>The security token could not be authenticated or authorized.
    For this question, please try to refer to:
    #ADFS issues - ID3242: The security token could not be authenticated or authorized.
    http://manyrootsofallevilrants.blogspot.in/2013/08/adfs-issues-id3242-security-token-could.html .

    Best Regards,
    Amy Peng


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Monday, October 14, 2013 8:00 AM
    Moderator
  • Hi,

    Sorry for late response.

    >> Security processor was unable to find a security header in the message. This might be because the message is an unsecured fault or because there is a binding mismatch between the communicating parties.   This can occur if the service is configured for security and the client is not using security.
    > First of all, please make sure Bindings are matched in the client and service, the security settings of the binding are same. As mentioned in the error message, the error can occur when the service is configured for a security and the client is not using security.

    The endpoint I'm using is defined in ADFS mex and matched with client binding according to these rules:
    http://blogs.msdn.com/b/alikl/archive/2011/10/01/how-to-use-ad-fs-endpoints-when-developing-claims-aware-wcf-services-using-wif.aspx

    My code was based on the first article you've referred. I've also tried to leverage some hints from the second one but with no luck.

    >>The security token could not be authenticated or authorized.
    > For this question, please try to refer to:
    > #ADFS issues - ID3242: The security token could not be authenticated or authorized. 
    > http://manyrootsofallevilrants.blogspot.in/2013/08/adfs-issues-id3242-security-token-could.html

    If I understand correctly this is something that should be done when setting RP on the ADFS side. All other standard web applications (MVC, Forms ASP.Net etc) integrates with this ASFS server, configured in the same way as in my case, without any problems, so I guess the problem lays somewhere else.

    I was advised to turn-off checking the CRL but I'm still getting the same error.

    Right now my code looks like this:

    	public class MobileAuthService : IMobileAuthService
        {
            private const string adfsBaseAddress = @"https://<my_ADFS_hostname>/adfs/services";
            private const string endpointSuffix = @"/trust/13/usernamemixed";
    
            private const string relyingPartyAddress =
                "https://<my_WCF_service_address>/Auth.svc";
    
            public string AuthenticateUser(string username, string password)
            {
                var binding = new UserNameWSTrustBinding(SecurityMode.TransportWithMessageCredential)
                    {
                        ClientCredentialType = HttpClientCredentialType.None
                    };
    
                var trustChannelFactory = new WSTrustChannelFactory(binding, new EndpointAddress(adfsBaseAddress + endpointSuffix))
                                                {
                                                    TrustVersion = TrustVersion.WSTrust13
                                                };
    
                var channelCredentials = trustChannelFactory.Credentials;
                channelCredentials.UserName.UserName = username;
                channelCredentials.UserName.Password = password;
                channelCredentials.SupportInteractive = false;
    
                var channelAuthentication = channelCredentials.ServiceCertificate.Authentication;
                channelAuthentication.CertificateValidationMode = X509CertificateValidationMode.None;
                channelAuthentication.RevocationMode = X509RevocationMode.NoCheck;
                
                var tokenClient = (WSTrustChannel)trustChannelFactory.CreateChannel();
    
                var rst = new RequestSecurityToken(RequestTypes.Issue, KeyTypes.Symmetric)
                    {
                        AppliesTo = new EndpointReference(relyingPartyAddress),
                        ReplyTo = relyingPartyAddress
                    };
                var token = tokenClient.Issue(rst);
    			
    			// do some token-related stuff
    
                return token.Id;
            }
    	}


    Monday, October 21, 2013 6:26 AM
  • Hey, is this issue resolved...

    i am having similar issue, looking for help. Please let me know, if you are able to fix.

    Tuesday, January 28, 2014 7:23 PM
  • Hi vsssrinivas1985,

    Yes, it was resolved. The problem was the endpoint I was using. My organization uses non-standard solution in place of ADFS (3rd party software) and completely different endpoint was configured for active clients - not only version of binding (WSTrustFeb2005) but also the path on server.

    When I've changed these parameters and specified AppliesTo in RST I've started receiving a valid token in response.

    I guess the best option is to ensure with your administrator that you are using the right, configured on server side, endpoint and provide the proper parameters in binding/RST. Different STS vendors may not consider the same settings as default.

    Wednesday, January 29, 2014 6:53 AM