It would probably depend on your application, as to when the job requiring the HttpSession object is scheduled. If some user action schedules the job, you would probably have to pass the session as part of the JobDataMap.
Otherwise, you would probably need an HttpSessionListener to track created/destroyed session in a list of some sort, and this list would have to be available to your job.
It would definitely depend on your application, and would almost certainly be a VERY BAD IDEA.
HttpSessions are controlled by the web application framework. Their lifecycle controlled by the container. If you stick it in a job data map it is going to get cloned and serialized and at best end up a disconnected copy of the session that the Job sees. There are good reasons the Java EE specs don't give any access to HttpSession outside of request.getSession().
Rather than giving the job a handle to the session, you should take whatever the job actually needs (what it would be fishing around in the session for), and stick THAT in the JobDataMap.