We have few biztalk 2010 applications. For connecting oracle we are using wcf-oracledb adapter. I am trying to implement Enterprise SSO for connecting oracle. I have configured SSO by creating affiliate application and assigned it to pipeline. while running interface getting below error
Error details: System.Runtime.InteropServices.COMException (0x80004005): Unable to redeem ticket, no ticket exists in the message.
at Microsoft.BizTalk.Interop.IBTSTicket.ValidateAndRedeemTicket(Object message, String applicationName, Int32 flags, String& externalUserName)
at Microsoft.BizTalk.Adapter.Wcf.Runtime.WcfClient2.ApplyClientCredentials(ClientCredentials clientCredentials, IBaseMessage message)
at Microsoft.BizTalk.Adapter.Wcf.Runtime.WcfClient2.CreateChannelFactory[TChannel](IBaseMessage bizTalkMessage)
at Microsoft.BizTalk.Adapter.Wcf.Runtime.WcfClient2.GetChannel[TChannel](IBaseMessage bizTalkMessage, ChannelFactory1& cachedFactory)
at Microsoft.BizTalk.Adapter.Wcf.Runtime.WcfClient`2.SendMessage(IBaseMessage bizTalkMessage)"
Am I missing anything in configuration? How to resolve this error?
You need a custom pipeline to attach a sso ticket to your messages.
Refer to this post:
http://blog.csdn.net/cnzee/article/details/7994243
(disclosure: it's my blog post)
Option A: If you are trying to map the caller from the Receive Location through to the Send Port your host need to be trusted.
Option B: If you are using SSO Affiliate to store credentials for BizTalk to use then you need to create the SSO Ticket in the message.
The quickest way to do this is to use the BizTalk Business Rules Engine and use the CreateSSOTicketContextProperty action.
Let me explain why this is necessary. What the SSO Affiliate was intended to be used for is that you had the caller authenticate against the receive location (e.g. a web service) and the credentials of the caller would be passed through to the send port in a SSO Ticket which would then be mapped using the SSO Affiliate user mapping. This would happen when you mark the Host as Trusted.
Update: A colleague of mine has also said you need to confirm that tickets are enabled on the Affiliate Application in SSO Administration
Related
ADFS server 2016 supports openId connect. I have external organization that hosts ADFS server , I want my web application to get authenticated from External ADFS server using openIdConnect .
Question : As per Microsoft docs . If we want to consume external organization's ADFS we should host ADFS in our organization also. My application should trust ADFS hosted inside my organization ,instead of trusting external ADFS directly.
Here I want to know why we cannot directly trust External ADFS using opendiconnect ? It seems possible. what is reason of not trusting external ADFS directly?
Both models work. If your application plans to have users from multiple organizations, it is better to have your app trust an internal org ADFS which can then be federated to multiple of these organizations with simple configuration changes. This makes the application simpler where it is dealing with only one IDP. An additional advantage for having an internal ADFS is that any authentication policy changes can be managed fully at internal ADFS layer and not potentially requiring application changes.
However, if your application is only going to support one external organization, you can do this directly in the application. Both models work for this.
Hope that helps.
Thanks //Sam (Twitter: #MrADFS)
I have a Java app running under Websphere Liberty on IBM Bluemix. I need to be able to authenticate users 3 different ways - Basic Auth, SAML SSO, and OpenAuth SSO, in that order.
I can set up the app to do Basic Auth (using custom code) or SAML SSO (using the Bluemix Single Sign On service), but can't figure out a way to configure it to handle both at once. (I haven't even looked into how to do OpenAuth yet.) If I configure the app to use the Bluemix SSO service, then my app never sees the incoming requests to check for a userid and password to try Basic Auth before the SSO service grabs it.
I tried changing the redirect URL in the SSO service to an endpoint inside my app, but then all I get is
CWOAU0062E: The OAuth service provider could not redirect the request because the redirect URI was not valid. Contact your system administrator to resolve the problem.
I can't be the only one that needs to do this. Can anyone tell me how they did it?
We are using WS02 ESB to create cloud app connections to our platform.
Our current issue: If we want to connect to any app (take salesforce as an example), we need the following details:
UserName
Password
Token
As a pre-requisite, the salesforce account should be API enabled.
We thought of using SSO in backend to avoid (3) and (4), but it's not possible with SAML(SSO).We are looking into ways to connect and publish data to salesforce with just Username(1)/Password(2). In this process of evaluation, SSO is one of the options
Any suggestions on how we can get the below details for APPS would be much appreciated!
• How do we get Token
• How we accept only the accounts where API's are enabled.
As far as I understand what you need is to call an SAML SSO secured backend app (i.e :- salesforce)?. If its the case you may use WSO2 Identity server for this purpose.You can obtain tokens from it.Further You can use this guide and this to call SAML secured backends through ESB.
Hope this helps.
You can use ESB Connectors to connect with Salesforce API. You can find Salesforce SOAP connector (which uses the username, password, and security token for authentication), Salesforce REST connector (which uses OAuth protocol) and Salesforce bulk connector (which also uses OAuth protocol) at WSO2 Store.
In WSO2 we have 150+ ESB connectors to communicate with third party API's via ESB. You can download the connector from WSO2 Store and can follow the documentation here. In connectors we have the mechanism to connect the third party API's(For Example In salesforce SOAP based connector we had the username password flow and for Salesforce REST connector we had oAuth 2.0 flow and the username password flow). In all connectors you just call the init method to get the Token to access the API.
We are trying to federate our application, so that our customers can gain access to our application using their respective corporate identities.
Well, I understand the mechanism of federation process, I’ve been able to setting up ADFS and I’ve modified the code of our application for accepting claims into my lab environment and all work fine.
In the next weeks I’m going to build a federation trust between ADFS and our customer’s product (Ping Identity) and I need your help to understand what kind of information I’ll have to exchange with customer’s IT department to complete that step.
I’ve never been experience with Ping Identity products.
Appreciate any help.
Many Thanks
I am going to make a couple of assumptions about your application, mainly that it is .NET application hosted on IIS. This type of application integrates Windows Identity Foundation (WIF) using tags in the web.config and then reads the authenticated users identity information via the Claims Identity object passed to your application. In this case your application is referred to as the Service Provider (SP).
If your customer is using PingFederate, the integration is straightforward in that a WS-Federation SP Connection would be configured on their server referred to as the Identity Provider (IdP). If your customer is using PingOne, then the integration will be tricky.
The information to exchange for PingFederate is driven by the configuration in the configuration in web.config. You need to configure the thumbprint which is based on the digital signing certificate of the WS-Federation response containing the SAMLv1.1 token. Your customer will be able to provide the thumbprint value. You will also need to configure the federated authentication URL, issuer, and realm, which is the information about PingFederate IdP server. The issuer is the URL for your SP application to redirect to the PingFederate IdP server, along with the realm which equates to the PingFederate SP Connection. Be sure that you configure the audienceUris to be the same value as the realm. The PingFederate administrator will need to know your Service URL endpoint which is your SP application endpoint to receive the WS-Federation response with the SAMLv1.1 token.
I am trying to set up the CRM Email Router to allow our internally hosted ADX Studio Portal to communicate with our externally hosted Dynamics CRM instance.
I have set up the Configuration profile to meet the requirements of our exchange server and created a deployment to an online service provider with the necessary details.
When I attempt to load the data the Email Router Config Manager states that it was unable to retrieve the data:
Metadata contains a reference that cannot be resolved:
'https://CRM.URL/XrmServices/2011/Discovery.svc?wsdl
When we traced the email router with Fiddler the request receives a 407 Proxy Authentication Required message:
Your credentials could not be authenticated: "Credentials are
missing."
We have tested the Email Router tool on a personal network (with no proxy requirements) and everything works correctly. However once we are on the internal network which requires the proxy the Email Router Config Manager no longer works.
We have tried using the Dynamics CRM SDK and and the crmsvcutil.exe command line tool but are not sure how it actually tells the Email Router what configuration to use.
Any help is greatly appreciated. Thanks.
The only way to resolve this is to add an authentication bypass on proxy server for the server and/or service account of the email router.
You can try add section to email router .config file, with proxy settings. This is .net app, so it should pick it up. I never tried this for email router, but might be worth a shot. look here for details
The answer we received from a MS support technician was "you need to ensure that the proxy will let through (without any modification) any requests to the CRM Web Service”.
We also tried modifying the .config file to include the proxy settings but it didn't work.
We are going to open an official case with MS. Will let you know if we ever get it working.