To secure the communication channel, does EPIC interconnect web service (especially personal management API) supports WS-Security?
To make channel secure between caller and Interconnect web service, the only solution is HTTPS and PKI (public key infrastructure) authentication. Is this a correct statement?
Related
When trying to binding any Bluemix apps to a pre-configured Secure Gateway service, the Secure Gateway is not in the list of services which can be bound to apps. Is there a different way to bind a nodejs app to a Secure Gateway instance?
Applications can no longer be bound to the Secure Gateway service. Binding was possible in previous versions but provided no additional functionality to the application.
To have your application use the connectivity provided by Secure Gateway, your application simply needs to call the cloud host:port provided by your destination.
When using a passive client (say web browser) and are using WS Federation with an STS such as ADFS, SSO is achieved to the relying parties. Is this apart of the WS Federation specification (that is, when using passive clients SSO will be achieved with WS Federation) or is this an implementation detail of ADFS (that is, ADFS sets a cookie so you only need to authenticate to ADFS once.. just beacuse the Microsoft developers thought it would improve user experience)?
It is a standard which is also supported by many other products.
https://en.wikipedia.org/wiki/WS-Federation_Passive_Requestor_Profile
http://janbernhardt.blogspot.com/2014/12/understanding-ws-federation-passive.html
WS-Federation Passive Requestor Profile is a Web Services specification - intended to work with the WS-Federation specification - which defines how identity, authentication and authorization mechanisms work across trust realms. The specification deals specifically with how applications, such as web browsers, make requests using these mechanisms. In this context, the web-browser is known as a "passive requestor." By way of contrast, WS-Federation Active Requestor Profile deals with "active requestors" such as SOAP-enabled applications. WS-Federation Passive Requestor Profile was created by IBM, BEA Systems, Microsoft, VeriSign, and RSA Security.[1]
We have developed a web application using angularjs and html5 and Node.js. This web application is hosted on Bluemix using the Node.js runtime. This web application calls an external RESTfull service (we are invoking the REST service using angularjs) which was developed by a third party. This REST API requires an HTTPS connection to call the service. The SSL certificate and certificate password are provided by the API development team. Our problem is how to configure the SSL certificate on Bluemix to call the external REST service over SSL from the web application. Can anyone please help us? Thanks in advance for your help.
To do this properly I would advice to create an API Management Service, where you add your external service as an API together with the SSL settings. You then call this API (proxy) without SSL from your node.js bluemix app.
The proxy will care for SSL, forward the request to the actual service implementation, and provide you also with debugging and analytics capabilities. With having API Management in place, you also benefit from a central place that manages your SSL certificates.
I have a web application (gwt) that is running on a tomcat application server. This web application consumes several web services (login, application data transfer, queries, etc.). The web service client on the tomcat is implemented as apache axis2 web service client.
For user log on I provide a form in the web application with username and password. This data are transmitted via web service to authenticate the user.
It is planned to change the hole authentication mechanism to client certificated based authentication. The authentication still should be done on the web service provider side.
So my system has three relevant components: the web client, the tomcat application server and the web service provider.
Every user of the application has its own private client certificate (PKI Token, X.509- Auth-Cert). When the user connects to the web application his certificate is requested.
How can I forward the client certificates for use in the web services? (The tomcat will not be responsible for authentication).
1.) Is there a way to intercept the request and extract the client certificates before authentication error occurred?
I found some information about Servlet Filters what sounds really good, but I’m not sure where to implement it to intercept the certificates before they are verified against tomcats keystore.
2.) If it is possible, how can I pass after the client certificate to the web service?
Thank you for reading
No, not really. The real piece used in authentication is the private key associated with the certificate, not just the certificate itself. And, typically, you have no way of retrieving that from the web client. Therefore, you cannot really pass-through the credentials you receive from a web client on to the web service client. The certificate itself is readily available, but is useless for authentication without the corresponding private key.
We are doing a Cloud POC, we will have applications hosted in the cloud that can only talk LDAP. Is there any system/appliance/virtual directory in the cloud that can appear to be an LDAP server from the application side, and on the output side talk SAML/REST based over the Internet to talk to our SSO product that can authenticate users against our corporate LDAP, which is tucked inside our internal firewall?
You need to deploy an Identity provider connected to the ldap. You can adopt CAS or SAML technology.
In that wikipedia entry you can check the differents products (commercial and free software):
http://en.wikipedia.org/wiki/SAML-based_products_and_services
Most of them support Ldap as the authentication source backend.
Also Take a look on this thread:
Way to single sign on between PHP, Python, Ruby applications
The emerging SCIM (System for Cross-domain Identity Management) protocol might make more sense for the use case you're illustrating. It's intended to provide a simple REST API around an identity store so you can perform Create/Read/Update/Delete operatons. What will be available could theoritically be controlled via some policy within a SCIM server to alloy your clients to essentially interact with the backend LDAP directory.
Many products are adopting the SCIM standard now, such as ones from Ping Identity, Salesforce and UnboundID.