I have two questions.
How to decide which one of the following is best for me to choose as my authentication method?
Sign Message with X509 Certificate
Require Mutual TLS
How to implement the two authentication methods?
I am using a Rails 4 app as my Connect API endpoint.
What's best for you will depend on your situation and priorities.
Sign Message with X509 Certificate
This can be used to verify or prove the source of the message. In this case DocuSign. This could be useful for auditing purposes.
Require Mutual TLS
With Mutual Auth TLS both the sender and the receiver verify each other using certificates. So the receiver knows the communication has been initiated by DocuSign, and the DocuSign service verifies that the certificate used by the receiver is as per configuration settings in the DocuSign console. The aim here is to prevent a Man-in-the-middle type attack where the communication could be intercepted and modified/recorded by an attacker.
This answer talks about the differences in more detail.
I think the key point is both approaches solve different problems, depending on your situation you may require one, both or neither.
Regarding implementation, TLS is typically done at a server level, so may require only configuration and no application code. XML signing on the other hand is typically done within the application itself.
Related
I need to centralize authentication to my rest web services and make this authentication the same for all of our webservices. So I started writing an external web service to take care about the authentication.
To keep compatibility, since the authentication was performed using a HMAC signature (signed using a private key) alongside the single request (so there is no token of any sort) I thought to make all web services to send the HMAC included inside the incoming request and the StringToSign (a representation of data used to generate the HMAC).
So the Authorization service can (knowing the private key) try to compose the same signature, if it matches then answers with 200 OK and with a JSON object saying "authorized".
All this communication happens over HTTPS, but I'm trying to figure out what could happen if someone would intercept or modify this answer, making a 403 Forbidden to become 200 OK...
Should I use some sort of way to recognize this is the original answer? If so, what could I do?
I do agree that ssl certificates released by CA's are secure, but how could I make sure my HTTPS layer has not been compromised allowing an attacker to modify authorization responses?
P.S. please provide some standard solution if any, I don't want it to be related to the technology I'm using right now, since each service may use its own stack and I don't really want it to be .NET or something else because there's a proprietary implementation for the authentication mechanism.
All this communication happens over HTTPS, but I'm trying to figure
out what could happen if someone would intercept or modify this answer
This is what the S in HTTPS is for: SSL guarantees integrity of the message. If the attacker forges the request, the client will notice it.
You can ask the experts at #security.
I've recently had to implement XML messaging with two large entities that required us to provide an SSL client certificate as well as sign the SOAP message body with a different signing certificate. Aside from redundancy, does the signing of the message body WITH A DIFFERENT CERTIFICATE provide any additional protection?
Edited to provide clarification of the question and point out the years-long misunderstanding between myself and EJP.
The value of signing the message in addition to using SSL with mutual auth (client cert) is that you get non-repudiation. However, you get that whether or not the client cert is used to sign the message or a different signing cert is used.
Signing the message provides legally enforceable non-repudiation over the transaction. You have proof that that client and only that client could have sent that message, and you can repeat the signature verification in court to demonstrate. SSL gives you the same thing technically at a lower level, but you don't have any way of getting the signature out, so you can't produce it in court: you are down to handwaving in evidence, as opposed to an actual digital signature, which is a legal signature and thus prima facie evidence.
I don't know that I'd term it "protection", but those are two different things. SSL certificates serve to verify your identity for encryption/transmission purposes.
SOAP signing allows the end user to verify that the XML has not been altered since the creator (you) signed it.
With transport-layer security, your security ends at the transport layer. By signing the SOAP message, you are providing end-to-end authentication for the application layer.
Without the SSL client certificate, anyone on the internet can talk to your back-end servers. That increases your attack surface.
Without application-layer security, imagine what could happen if an attacker gained control of an SSL load balancer / reverse proxy. (They could send any SOAP message they want to your back-end server with no authentication?!)
So it seems like they both do provide some value, yes.
The other question I would ask is, how are the keys (that is, SSL client certificate and SOAP signing certificate) secured? If it's trivial for an attacker to gain control of both keys, that would diminish the returns of this approach.
By using a different key to sign SOAP messages than to authenticate your connection, you also open up more flexibility around how you do your PKI. For example, your network administration team might want to issue one SSL client certificate per organization, but the application team might want one SOAP message signing certificate per entity in that organization.
Why WS security is needed to provide tokens,signatures etc if there are ssl communication to achieve this purpose? How can WS security used to provide integrity,confidentiality and authenticity that ssl can't provide?simply why ws secuirty(If possible can you provide any example)
If business partner of paypal using paypal's web service in its website.If that web service is asking for username and password of its customer,how paypal can protect customers data from there Business partners?How soap transaction can take place between customers,paypal and its business patners?plz can you explain how WS security concepts ( provide integrity, confidentiality,authenticity) in this case?
The main difference is that HTTP related security mechanisms secure the transport layer of the web service, and WS security addresses a higher level of abstraction.
similarly, you may have also security solutions in higher (for example: encrypt just a specific password field in a web service) or lower levels (like VPN)
Different scenarios will require different security measures in different layers
Some examples:
Web Services are not limited to HTTP transport - your environment may include other transports (like messaging using JMS, MSMQ, etc). setting up security at the Web Services layer (rather then the transport layer) will allow you to use a common mechanism for the whole environment.
Another issue is that http level security information is "pealed" as you go higher in the Web Services Stack - for example, in many places you wont be accessing the service provider directly, but through a central ESB (Enterprise Service Bus). the ESB acts as a central hub for services, and may also perform tasks such as logging, routing, publishing to multiple service endpoints, etc.
When using an ESB the http connection is broken at the ESB, and the service gets a new http connection originating from the ESB - thus http security mechanisms cannot offer end-to-end security.
WS Security information however can be preserved even if the messages are routed through an ESB
What you describe in you last comment appears to be not related to the previous answer
Do you mean they have a mechanism like OpenID or kerberos, where you can use your credentials from one site to access a different site?
This isn't specific to web services, and there are various existing protocols to do it (my guess is that they use an existing protocol). Of course a similar mechanism can be developed using WS Security standards.
The kerberos protocol for example works like this:
1. The user authenticates to the security server
2. the security server replies with a signed message (called ticket) saying "the user 123 has been authenticated"
3. The user uses this message to prove that he is indeed user 123 to the 2nd site, without the need for the 2nd site to actually get his username password.
This protocol is based on encryption and cryptographic signatures - both are available using WS security.
SSL (TLS) security will protect the user from eavesdropping. But it won't protect you (your site) from malicious users. You're still vulnerable to buffer overflows, SQL injection and so on.
For a great example watch the "How I met your girlfriend" talks by Samy Kamkar at Defcon (shorter) and at Blackhat (longer). Samy explains using web application vulnerabilities to breaking into an account (in this case it's Facebook) of someone who uses SSL.
The main difference between SSL and WS-Security is, SSL is transport level but WS-Security is message level... In other words when you use SSL - as soon as the message left the transport channel - its not secured. But with WS-Security message will be still secured and message security is independent from the transport channel.
With WS-Security,
Authentication --> UsernameToken
Non-repudiation --> Signature [XML
Signature/WS-Security] Confidentiality --> Encryption [XML
Encryption/WS-Security]
Integrity --> Signature [XML Signature/WS-Security]
Pure SSL provides Authentication/Confidentiality and Integrity - but not Non-repudiation.
2-legged OAuth is a standard to support Non-repudiation over SSL.
Thanks...
WS or Web Service Security is an extension of SOAP which applies security to different web services. Ws-Security uses XML signatures and encryption to provide end to end security. Main focus of this protocol is to specify how integrity and confidentiality can be enforced in messages exchanges between user and service provider on web such as Paypal. This service also allows communication of different security token formats like SAML, X.509, Kerberos etc. Unlike HTTP protocol which mainly focuses on providing security at transport level, WS security mechanism implements higher level of abstraction in application layer and provide encrypted security solution.
Since need of security is different on every platforms, these two standards focuses to meet distinguish need of such security platforms. With the help of this security, end to end security, non- repudiation, reverse proxy, transport bindings etc are improved.
In general terms you can say that this service is another method to provide better security to data exchange platforms and user’s privacy. There are many other services/software which does same task like TOR (provides integrity to user privacy), ScrapeSentry (a service which provide security from bad bot traffic and spam), Distil Network (another service to block spam on web spam) etc. However concept of every security mechanism is different but their main motive is to provide constant and reliable security to user as well as businesses.
Good day people,
the SSL/TLS technology is a security technology. Its goal is to protect the user from having his/her information (credit card, address, tel number...) being stolen by a hacker. The SSL certificate will protect the website and each person who connects on the website will be sure to have a secured environment.
The quality of the security depends on the type of certificate installed on the website in question, whether it is DV (Domain Validation), OV (Organization Validation), EV (Extended Validation), if the SGC technology is present or not.
If you have any other questions, you can have more details here.
I have been doing some research lately about best approaches to authenticating web services calls (REST SOAP or whatever). But none of the Approaches convinced me... But i still can't a make a choise...
Some talk about SSL and http basic authentication -login/password- which just seems weird for a machine (i mean having to assign a login/password to a machine, or is it not ?).
Some others say API keys (seems like these scheme is more used for tracking and not realy for securing).
Some say tokens (like session IDs) but shouldn't we stay stateless (especially if in REST style) ?
In my use case, when a remote app is calling one of our web services, i have to authenticate the calling application obviously, and the call must - if applicable - tell me which user it impersonates so i can deal with authorization later.
Any thoughts ?
So, you have User -> clientServer -> yourServer, yes?
You need to authenticate clientServer -> yourServer, to make sure not just anyone can talk to your server.
If this is an established trust relationship (i.e. you guys chat, sign documents, and do other things "out of band"), then you can simply use SSL certs, certs that you can sign.
Basically you set up your own Certificate Authority, create a root certificate, and then create a client certificate signed by that root certificate.
You then send that certificate to the clientServer, and don't let anyone connect to your service that doesn't have a certificate signed by your root certificate.
If the client ever ceases their relationship, you can revoke their cert and they can't talk to you any more.
As for identifying the User, that will need to be part of the API. The Client should authenticate them properly, and then forward any credentials to you that you require.
That can be a first class part of your web service (like a parameter), or if you use SOAP it can be passed along in a SAML attachment in the SOAP header, that you can then extract.
WS-Security has about 8000 ways of securing SOAP web services, as you may have discovered.
So, it kind of depends on what you want to do, and other requirements. But given what little you have, this should work peachy.
Don't know much about encryption...
Say I'm preparing a SAML request to submit to an identity provider. Why would I need to apply an x.509 certificate to this request? Is transmission over SSL alone not secure enough?
In the case of SAML, message-level security (i.e. the XML itself is signed and sometimes encrypted) because the communication involves parties that don't communicate directly. SSL/TLS is for transport-level security, only used between the two parties that are communicating directly and for the duration of this communication only.
Depending on which SAML binding you use, the dialog can look like this (e.g. along the lines of Shibboleth):
User's browser connects to Service Provider (SP)
SP gives the user a SAML request, not necessarily visible, but hidden within a form or equivalent.
User's browser (in a direct connection to the IdP) sends the SAML request to the IdP.
The user authenticates with it and gets a SAML response back.
The user's browser sends that SAML response to the SP.
In this scenario, there is no direct SSL/TLS connection between the SP and the IdP, although all 3 parties are involved. (Some variants of this involve a back-end communication between SP and IdP for attributes, but that's a different problem.)
An SSL/TLS connection wouldn't be sufficient for the IdP to know that the SAML request came from an SP for which it's allowed to authenticate and release attribute, since the connection to the IdP comes from the user's browser, not the SP itself. For this reason, the SP must sign the SAML request message before handing it to the user's browser.
An SSL/TLS connection wouldn't be sufficient for the SP to know the SAML response came from an IdP it trusts. Again, that's why the SAML response itself is also signed.
What applies to signing also applies to encryption, if the middle party, i.e. the user, isn't meant to see what's in the SAML message and/or if the connection between the user and the SP or IdP isn't over SSL/TLS (usually, it should be over HTTPS).
Yes - SSL is enough - but SSL is only point-to-point. You cannot secure your connection using SSL if there are a few intermediaries in the way between your source and your target machine.
In that case, e.g. when transmitting over the internet, you must safeguard the actual message, instead of the transport-level. That's why you need to encrypt the XML (or at least parts of it).
Marc
All that HTTPS will do is encrypt the communication between two points and prevent eavesdroppers -- it won't confirm who it was that sent the message. Neither will it assure secure communication if your message is then forwarded.
If you sign your request with the X.509 certificate you can be assured the decryptor has the shared secret contained in certificate. In other words, you can be assured the message can only be decrypted by the organisation you want it to be decrypted by.
In your case, the X.509 encryption requirement means that you should be assured that the identity provider is the only organisation that will receive your request.
A useful Wikipedia primer is here.
Most likely because they want to authenticate you (the client). HTTPS can be used for client authentication, but it rarely is in practice.
In practice, you could use HTTPS (SSL/TLS) to protect your SAML message. But you would want to use two-way SSL certificate verification/validation, meaning your client would need to verify the server's X.509 certificate and the server would need to be configured to perform client authentication, which would require it to check an X.509 certificate that the client presents. So, the client would need its own certificate anyway.
SSL/TLS is not really designed for this...it was/is designed to protect web traffic from being seen while in transport and for the client to be able to tell what server they are talking to and sending sensitive information to (it was really designed for e-commerce where the client (user buying something) knows who they are sending their credit card information to). In the case of SAML, the whole point is for the parties to know that the information they are exchanging has not been altered in transport and that each is talking to who they think they are. Using certificates to sign/encrypt that message itself accomplishes that.