client with the credentials of the authenticated user

[davidhr82]

hi, more of a question.
can I use the node-expose-sspi client with the credentials of the authenticated user? basically to impersonate the logged-on user?
By using sso.auth() I can get the authenticated user but how do I pass along to another API call the same user credentials? The sso.client with 'fetch' uses the credentials of the logged on windows user and not the client.
Please help! urgent!

[beefster]

The client portion of this library is for constructing the http request with auth headers within a node.js process, based on the windows user that executed the process (http requests from browsers will attempt to do this automatically).

sso.auth() is meant to actually authenticate these headers on the server side, and obtaining the active directory result of such headers parsed from the request, if the authentication was successful.

What do you mean by "another API?" If you are passing to another service that is expecting to perform such authentication in the same way, you don't need to do anything in your middleware other than forward the request with its headers intact, that service should be doing the equivalent of sso.auth(). If you are able to mint them the token required for the separate service, do that in your service based on the result of sso.auth and preferably cache it.

If you need to extract the username and password from the request, that's not possible from the auth header, and defeats the purpose of it. Passwords are never stored in memory that way, only as (hopefully secure & unique to the authorized environment) hashes. So the most "secure" way to get plaintext credentials is just prompt for them, and make sure your servers are secure, and SSL is buttoned up in all directions to prevent man-in-the-middle.

If you're talking about other middleware/endpoints in your service, I recommend consolidating the sso functionality to the initial auth endpoint in which you mint (construct then hash using 'token_secret' password) and issue a JWT back to the client pending a successful sso.auth() result, and any protected user data for your app such as roles/privileges based on either the returned adUser information or entries in your service db, in its payload. The client keeps this token in session or local storage and uses in the authorization header for any requests to your service going forward. Your service's auth-protected endpoints first use a middleware which validates the token and parses its payload into the request object itself, somewhere like req.userData, then your endpoints can make use of userData. The token is perfectly secure so long as your token secret is never exposed outside of your server.

This is also much more performant than getting the whole AD report from sso.auth() every time. That should only be performed on login, and a strategy like the one above for all subsequent requests from that user, until they log out or token expires.