I'm asuming you are referring to the TLS Session ID as specified in RFC 4507
No, I don't think this will give you what you need. The TLS Session ID is a ticket provided by the server to the client which will allow the client to resume a session at a latter time (i.e. after existing session has ceased). This is focused at the TLS layer, which you can think of as a layer below your application layer. The TLS layer is all about establishing the secure connection and knows nothing about your application level.
When you first connect to a TLS enabled service, there is a handshake process between the server and the client which is used to establish the secure connection. With the use of the session ID, the handshake process can be reduced in subsequent connections - by providing a valid session ID, the client is essentially saying "Hey, lets hook up again and use the same encryption keys etc that we used last time. The server may say "Hey cool, lets go" or it may say, "Sorry, been too long, we need to re-negotiate".
As this is a layer below your application, the TLS session ID doesn't know if you are authenticated with the application or what your authorisation level is. Normally, this will only occur after the TLS connection has been negotiated and established. You cannot add this information to the TLS session ID as this is an encrypted value generated by the server side TLS layer. This also means your application cannot determine the user credentials from the TLS session ID.
If your users need to be authenticated and authorised, you really need to manage that in an application level session or cookie, you need to be able to verify it hasn't been modified and you need to include additional protection, such as CSRF protection tokens and you need to verify all of this on every request.