From Kerberos architecture perspective, according to this graph during TGS_REP Client gets a service ticket which is encrypted using TGS session key. After that Client takes the service ticket to Application Server to get a service.
I have seen that some document said that there is no interaction between TGS and application server. So my question is how Application Server decrypt the service ticket without TGS session key to verify the correctness of the service ticket?
The service ticket is encrypted with the server's longterm key known to the KDC.
Related
I am new to Kerberos and I am not sure how browser knows which KDC to contact for ticket for a HTTP service?
For example, I have an application (SPNEGO) running on www.xyz.example.com and my realm is example.com ( I have a linux server as KDC server), what will be the SPN created and how will browser contact KDC?
how browser knows which KDC to contact for ticket for a HTTP service?
The browser never directly contacts the KDC. Instead, it relies on the ticket cache maintained by the operating system. If the ticket for the specified service is not found in cache, then OS connects with the KDC and puts the new ticket in cache, from where the browser can pick it up.
what will be the SPN created and how will browser contact KDC?
General format of the SPN is <service class>/<host>:<port>/<service name>. If you have a web application running on xyz.example.com, then usually (not necessarily) the format of your SPN will be HTTP/xyz.example.com
SPNs are not defined automatically. Administrator has to register the SPNs at the time the keytab is generated.
We have a client/server based application that is developed internally. Clients and server communicate over a TCP/IP connection with an application-specific protocol. The clients run on Windows and the server runs on Linux. All machines are in the same Active Directory/Kerberos domain/realm.
Currently, the user enters a username and password when they start the application. The server checks the username and password (authentication). Based on the username, the server also determines access to resources (authorization).
We want to add Single Sign-On (SSO) capabilities to the application. That is, we do not want the user to enter a username and password but we want to automatically logon as the current Windows user.
Of course, determining the current Windows user has to be done securely.
I have come up with the following setup:
I use SSPI (Negotiate) on Windows and GSSAPI on Linux.
When the client connects to the server, it uses AcquireCredentialsHandle (Negotiate) to get the credentials of the current Windows user.
The client uses InitializeSecurityContext (Negotiate) to generate a token based on these credentials.
The client sends the token to the server.
The server uses gss_acquire_cred() to get the credentials of the service. These are stored in a .keytab file.
The server receives the token from the client.
The server uses gss_accept_sec_context() to process the token. This call also returns the "source name", that is the current Windows user of the client.
The server uses the "source name" as the username: the server performs no additional authentication. The server still performs authorization.
This works but I do have some questions:
Is this secure? It should not be possible for the client to specify any other username than the Windows user of the client process. If a user has the credentials to create a process as another user (either legally or illegally) than this is allowed.
Should I perform additional checks to verify the username?
Are there alternative ways to achieve SSO in this setup? What are their pros and cons?
What you've described here is the correct way to authenticate the user. You should not have to worry about the user specifying a different name; that's what Kerberos takes care of for you.
If the client is able to obtain a service ticket, then they must have been able to authenticate against the KDC (Active Directory). The KDC creates a service ticket that includes the user's name, and encrypts it with the service's secret key.
The client would not be able to create a ticket for the server with a fake name, because it doesn't have the necessary key to encrypt the ticket.
Of course, this all assumes that you've set everything up correctly; the client should not have access to the service's keytab file for example, and the service should not have any principals in its key tab except its own.
There's a pretty detailed explanation of how it works here.
I have deployed liberty app on IBM cloud. I have setup custom domain and selected "request client certificate" so that clients have to send certificate to access app over TLS. I see client authentication does work, but I do not get any client certificate information in my app. This makes client certificate authentication a bit useless, as I would want to know the id of client which accessed my app. Any help/pointers appreciated.
I looked at attributes of request. Two attributes are passed in request _com.ibm.websphere.servlet.uri_non_decoded_ with value /dummyRelPath and _javax.servlet.request.cipher_suite_ with value of ECDHE-RSA-AES256-GCM-SHA384 There's no attribute with name javax.servlet.request.X509Certificate passed in request.
Does:
X509Certificate[] certs = (X509Certificate[])
request.getAttribute("javax.servlet.request.X509Certificate");`
not return any certificates?
In cloud foundry on bluemix, your client should be handshaking with a DataPower proxy. That proxy adds a custom header to indicate the TLS client cert that was provided, then it is passed through the CF gorouter, then finally passed to the JVM.
WebSphere Liberty then surfaces that through the API above.
This is communicated through the $WSCC request header. If the API returns null, it's most likely that header was dropped or never set by the infrastructure, rather than making it all the way there and the API mysteriously losing track of it. You could dump the request headers, looking for this one in particular, and maybe something will stand out (some surprise hop/proxy).
Can I generate the LTPA2 Token Key without the need for any of IBM products like IBM WebSphere Application Server?
I'm trying to use datapower to generate LTPA token (based on authenticating user by username and password) and then reply back to the client with the LTPA Token. The subsequent requests from the client would have the LTPA token and IBM datapower would authenticate the requests based on the extracted LTPA token and then forward the request to a backend web server that is not IBM webspher server.
The flow is as per the below:
Client ―> DataPower ―> Backend Server (not IBM Server)
The client submits a request with the credentials (username/password)
in the authorisation header.
DataPower AAA, extracts the identity (Authroization http header with
username/password) and authenticate the user
DataPower Generates the LTPA2 token in the post processing step and
send it back to the client.
The client sends a request to access a protected resource protected by
DataPower AAA policy.
DataPower checks the request for LTPA2 token
If the token is valid, IBM datapower forwards the request to the
backend server.
If we don’t have IBM WebSphere Application Server, is there any way to
generate the LTPA Key file?
To generate an LTPA token you must have LTPA key. One way to obtain such key is to go to any Worklight installation [Worklight server because I am familiar with and tested it] and copy the LTPA.key file. Supply this to Datapower in post processing step and you are done.
That is all you have to do to generate LTPA token from Datapower. Let me know if you face any issue.
Ajitabh
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.