I have a scenario where my service which is an OSB need to act as a pure-passthrough service for a client sending a SAML token to a Service requiring the token.
We are using wss10_saml_token_service_policy on OSB Proxy Service and wss10_saml_token_client_policy on OSB Business Service.
My question is, for this simple token, do we require to establish a trust (importing my certificate to the Server Keystore, and client's certificate into my keystore)?
I know if SSL related policies or message encryption related policies are used, trust is to be established. But is it required for this policy?
FYI,
a simple SAML token doesn't require trust establishment. It simply checks for the subject in the assertion, and validates against the underlying LDAP, and if exists, it passes through.
Only message protection policies require trust establishment - importing certificates, registering keys in the keystores, etc.
Related
Does the client x.509 certificate encrypt the data as well as handle authorization?
Documentation says it handles authorization and message signing. But does that mean the data is encrypted in transit?
It is NOT encrypted when using Secure-Cluster with Certificates (Node2Node + Client2Node) with default Rpc-Endpoints. In Wireshark you can see the whole communication. It seems just for authorization.
Endpoints with https are encrypted of course.
Yes, a given x509 certificate will be used to encrypt the data while communication happens between a client and the cluster. As for authorization, it means that you could set what client certificates will posses 'SF Cluster Admin' privileges, and the ones that will allow only to query the info about your cluster.
In addition to the cluster certificates, you can add client
certificates to perform management operations on a service fabric
cluster. You can add two kinds of client certificates - Admin or
Read-only. These then can be used to control access to the admin
operations and Query operations on the cluster. By default, the
cluster certificates are added to the allowed Admin certificates list.
you can specify any number of client certificates. Each
addition/deletion results in a configuration update to the service
fabric cluster
I would like to know whether OSB plays a crucial role in terms of security apart from just behaving as a middle-ware.
Inbound Security:
Inbound security ensures that Oracle Service Bus proxy services handle only the requests that come from authorized clients. (By default, any anonymous or authenticated user can connect to a proxy service.) It can also ensure that no unauthorized user has viewed or modified the data as it was sent from the client.
You set up inbound security when you create proxy services and you can modify it as your needs change. For outward-facing proxy services (which receive requests from service consumers), consider setting up strict security requirements such as two-way SSL over HTTPS. For proxy services that are guaranteed to receive requests only from other Oracle Service Bus proxy services, you can use less secure protocols.
For each proxy service, you can configure the following inbound security checks:
Transport-level security applies security checks as part of establishing a connection between a client and a proxy service. The security requirements that you can impose through transport-level security depend on the protocol that you configure the proxy service to use.
For example, for proxy services that communicate over the HTTP protocol, you can require that all clients authenticate against a database of users that you create in the Security Configuration module of the Oracle Service Bus Administration Console. You then create an access control policy that specifies conditions under which authenticated users are authorized to access the proxy service.
Custom Authentication for message-level security. Oracle Service Bus supports client-specified custom authentication credentials for inbound transport- and message-level requests. The custom authentication credentials can be in the form of a custom token, or a username and password.
Message-level security (for proxy services that are Web Services) is part of the WS-Security specification. It applies security checks before processing a SOAP message or specific parts of a SOAP message.
Outbound Security
Outbound security secures communication between a proxy service and a business service. Most of the tasks that you complete for outbound security are for configuring proxy services to comply with the transport-level or message-level security requirements that business services specify.
For example, if a business service requires user name and password tokens, you create a service account, which either directly contains the user name and password, passes along the user name and password that was contained in the inbound request, or provides a user name and password that depend on the user name that was contained in the inbound request. For more information, see Section 2.1.15, "Creating Service Account Resources."
If a business service requires the use of PKI technology for digital signatures, or SSL authentication, you create a service key provider, which provides private keys paired with certificates. For more information, see "Service Key Providers" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.
More info (Oracle Official Documentation):
https://docs.oracle.com/cd/E29542_01/dev.1111/e15866/model.htm#OSBDV1476
Does kerberos encrypt only the authentication process or all client communications?
I was under the impression it was like a VPN for the LAN.
So that all LAN communications are encrypted. Just like all internet communications are encrypted with a VPN.
Regards
Aubrey
Kerberos is quite capable of encrypting traffic between client and server, but depending on exactly how kerberos is used in the application, it may or may not be using the kerberos session keys to encrypt the traffic.
The kerberos protocol provides the means to exchange a session key that can be used to encrypt message traffic after the initial authentication exchange. Encrypted message exchange is generally the default for protocols that actually use GSSAPI. See gss_wrap documentation
GSSAPI is a generalized API for doing secure network applications. Kerberos is the mostly commonly used driver underneath GSSAPI.
If the application does not use GSSAPI, or the native kerberos messaging libraries, then it is likely using TLS to encrypt the traffic or the traffic is not encrypted.
Kerberos message encryption was designed to support relatively long lived tcp based client/server applications ( think telnet or ssh ). The API does not always map well to the way current applications are architected. Kerberos support is often bolted on well after the application is under construction
and is only used for authentication.
Kerberos is an distributed service that is generally used for secure authentication only. It does neither ensure that a user has the required permissions to access a resource (that would be Authorization) however it may be used to encrypt arbitrary data. As per RFC 3961 "Encryption and Checksum Specifications" which extends and correct aspects of RFC 1510 the Kerberos protocol provides confidentiality and integrity services.
While Kerberos can be used to encrypt information passed between authenticated peers in many cases it only performs the authentication step. Thus, you will find that Kerberos is used as component in a secure environment to ensure a secure authentication with other components and protocols handling the authorization and the secure transport.
In the end, it heavily depends on your usa-case to determine if the tradeoffs between using Kerberos or something else as a transport protocol make sense for you.
While the Kerberos protocol can be used to provide encryption services on most platforms, microsoft provides no mechanism to do this directory. Instead GSSAPI may be used to call these services.
For example, Active Directory uses Kerberos for message integrity.
Similarly, you could use e.g. TLS or IPsec to encrypt your data on the wire and combine it with Kerberos for authentication. But again, this is another protocol performing the actual transport encryption and just using Kerberos as an authentication component.
Getting below error
Http Action - Request to host 'sipoc.cloudapp.net' failed: TrustFailure The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
while invoking below WCF RestService on https from Azure scheduler service GET job.
below is the webservice URL
https://sipoc.cloudapp.net/Service1.svc/GetPlayersXMl
Service URL is working fine.
Any help would be appreciated.
If I browse to the URL provided it indicates that the SSL certificate is not trusted.
"The security certificate presented by this website was not issued by a trusted certificate authority.
The security certificate presented by this website has expired or is not yet valid. "
Scheduler jobs will fail as it can't trust the endpoint. You can either use a trusted certificate or just use HTTP (instead of HTTPS).
Although I would never recommend this in production unless you know the cert is valid (i.e. self signed), you can override the default behavior and confirm that the cert is good.
Below is a sample on how to do it in C#. There are a couple of ways to write it. The advantage here is that it remains SSL encrypted (versus falling back to HTTP).
ServicePointManager.ServerCertificateValidationCallback = (sender, certificate, chain, errors) => true;
I have a mobile app that will be communicating with my webserver over https. My question is, do I even need to worry about installing a certificate since all traffic to this api will be headless?
In my understanding, SSL provides the encryption for a request, and a certificate establishes trust for the end user. Because these calls to my webserver will essentially be headless, I'm thinking I don't need to worry about the trust establishment.
Am I correct in this thinking?
You will either need a self-signed certificate or a CA-signed certificate in order to use HTTPS on your server.
If your certificate is not assigned to you by a certificate authority, then any connection you make will trigger an error in your URLRequest that you will have to handle. The problem with an untrusted certificate is that a malicious man-in-the-middle could fake data to and from your server with his own self-signed certificate, and possibly pick up authentication credentials or data that he should not have access to.
If you are dealing with any authentication credentials or other private data, I'd recommend just requesting a signed certificate. If you shop around, you can find cheap signed certificates for $10-20 a year, which is a trivial cost to protect your users.
However, if this is just a personal project (the only data you have to worry about is yours), or any data that you will be sending is freely available, a self-signed certificate may be enough.