I'm using cypress-ntlm-auth plugin in my cypress automation project, providing me windows authentication (Ntlm, kerberos etc.)
In particular, I use the ntlmSso option for Negotiate with my app. If the server sends an authentication challenge, the ntlm-proxy will perform a NTLM or Negotiate login handshake with the credentials of the user running the test client.
The problem is that I need to use a pre-defined user (to be used in my pre-prod environment) to make api requests, instead of the logged on user on the computer.
How can I do that? thanks in advance
The cypress-ntlm-auth library allows you to specify this with cy.ntlm(), by passing in hosts, username, password, and domain.
cy.ntlm(["my.host.com"], "myUser", "myPass", "myDomain")
Check out the docs here. Take note of their strategy on storing passwords.
Related
I have a server application, and the clients communicate with this server with a proprietary protocol which operates on TCP. It is not possible make any change to the existing client applications.
Currently the TCP connections are authenticated by the server application, with credentials stored in a database. I need to migrate user credentials to Okta from the database.
It appears that I can use Okta Authentication API in the server application to authenticate users. Also, none of the OAuth 2 flows or SAML doesn't seem to be suitable for my use case.
What is the best approach I can choose to use Okta to authenticate users in my user case?
If your server can see username/password in plain text, and can make http calls to Okta, then you can for sure use Okta for authentication. All you need is a call to /authn endpoint.
Make sure your password/mfa/authentication policies in Okta do not require 2FA and do not expire your password. Otherwise your server would need to be able to process responses from Okta, which would require MFA or change password
I am developing two linux programs, a CLI client and a server communicating via gRPC, and I now would like to authenticate users against a given private authorization server such as LDAP, Active Directory, etc.
I am confused regarding the various possible authentication flows. I think I can't use any classical flow including HTTP redirects since I shouldn't rely on a browser being installed or having internet access. I can't even define an endpoint I could redirect to (servers don't have internet access, and both are behind NATs).
So I was thinking of trying to store user's credentials as a JWT token file in the user's computer and then load it from my CLI client program to include it in my RPC requests and then validate it on the server-side. But, supposing I'm right, then what would be the best standard way of getting this token file?
If you had a browser you could use OAuth and the 'oob' (out of band) method where the CLI opens the browser and after the user authenticates it displays a number which the user copy/pastes into the CLI. This how my flickr backup CLI works. The number they copy/paste is because the CLI has no OAuth endpoint and the number is their access token to allow me to call the flickr api on their behalf.
If you can't use a browser the CLI can just accept a username/password from the user, send it to the server and receive a token in return. You don't really need anything fancy like JWT. A simple UUID would be enough. The UUID 'asserts' that the user is allowed to access the server's other RPC methods. The server would validate the UUID token to make sure it's still valid. If you need user information from the token, the server could do that. Keeps the user information off the client's disk and only the CLI can access that information, if the token is still valid.
So in effect, you need a new server RPC method, perhaps, authenticate, that accepts a username and password and returns a UUID token. All other RPC methods then need to accept that token and validate it before performing the requested function. As part of the server-side authentication process, the server could associate that token with the user information it got from the LDAP server so you don't need to store that information on the client. Lets you encrypt it on the server too and if the client needs it, it asks for it using the UUID token if it's still valid (time to live?). If it's no longer valid, the client just needs to ask for username/password again and the server can re-authenticate the user via LDAP and refresh the token and user information.
gRPC has authentication protocols but the SSL/TLS doesn't seem to match your needs and the OAuth won't work as you don't have a browser. So perhaps rolling your own simple token service (authenticate) combined with LDAP authentication might be a workable option.
We are developing an inhouse application, which will be distrubuted via Mobileiron. I can get the active-directory/mobileiron user name and device id from mobile iron. What i need to know is, when a web service call comes to my api, i want to make sure the call is coming from a client who is logged in to my app using mobile iron. I have no idea how to do this. My manager doesn't want to use Kerberos for single sign-on and all the documents i could find contains messy information.
Can someone please show me the way in some detail? do i need to use certificate or Sentry? How should i do that?
I am running out of time so any help would be appreciated.
From my experience, you do not need to use Kerberos. You can use certificate-based authentication and have Mobile Iron configured to return the certificate. If you are using AppConnect API you can have the base-64 encoded cert (.p12) and password provided as part of the configuration object (via AppConnect.sharedInstance().config), which would then be passed along to the server for authentication. The LDAP user's email is embedded in the cert, so the server can associate it to a user.
There's also the option of using "pass-through" authentication which basically trusts the client is authorized. Not the safest option.
Several sites, including this one, are using OpenID to authenticate their users. And of course, OpenID is a good solution to manage user accounts, simply by linking them to their OpenID account.
But are there similar solutions that could be used for desktop applications? I know there's CardSpace, where you create a custom ID card to contain your identity and optionally protect it with a pincode. But are there more alternatives for authentications on a desktop system or on systems within a local intranet environment?
And yes, I can write my own system where I keep a list of usernames and (hashed) passwords and then build my own login system but I just hate to invent my own wheel, especially when I need to keep it secure.
I would recommend that you look into the option of building an STS (using WIF, aka Geneva) and use (active) WS-federation in your windows app. Or if you can wait that long, just use Geneva Server when that is released.
We have a solution that works more or less like this:
Desktop tool prompts the user for ID/password
Desktop tool sends the ID/password over an encrypted (SSL) channel to the server.
Server initiates an HTTP request to a known URL of a login form and inputs the username and password as if they were form fields.
If the HTTP server responds appropriately, the server accepts the client as authenticated.
The target of that HTTP request should be tied to whatever single sign-on system that you use for the web application environment. In our case it happens not to be OpenID but it could be.
I am working on a site where users can login to get more private information.
My client has another site else where that uses nt authentication for accessing it.
What they want to do is have a button on the site I am working on under the private area that will send them to the nt authenticated site, but not require them to log on to that site instead passing the username and password that they used to log into my site to the other site for them.
Is it possible to do this? and how would I accomplish it? Is there a better way to do this?
Here's an (untested) theory, the details of which will greatly depend on what types of authentication the Sharepoint site will accept. I'll tackle Basic, since it's the easiest.
You'll write out some JavaScript that uses XMLHttpRequest to submit a request to the Sharepoint site, and add their username and password to the request headers. Their browser will run that JavaScript, and get logged into the Sharepoint site.
Now, when they click the link, the client's browser should have the cached credentials to send to the Sharepoint site.
Possible issues:
XMLHttpRequest does not allow cross domain auth
Browser and XHR don't share auth info
Sharepoint and XHR can't agree on auth method
Another option is to proxy the connection to Sharepoint, which allows you to login server side (bypassing XHR limitations and browser security) - but requiring load on your server and possibly some URL target issues.
How will the other site validate your username and password?
Ideally your site shouldn't even be remembering the user's password to be able to pass it to another site (you store hashes of the password, not the password itself, and only use the actually password during validation).
What if your site provided a token to the user, who presents that token to the new site, which in turn asks your site to validate the token. Basically the second site is trusting you to tell them who the user is.
This all breaks down if the second site is actually using the Windows accounts for anything other than just retrieving a user name (for example permissions on the underlying file), since the user is not logged on as the actual Windows user account in this scenario.
If you need to authenticate against the second site, you may need to spawn a new thread and call the windows LogonUser API. Once you have the security token, assign it to the new thread and do your connection via that thread.
LogonUser requires enhanced privileges, and isn't Managed code, so there are some pretty severe hiccups to using it. But that's been the only work around I've been able to find to get a Forms authenticated site talking to a Windows Authenticated Service/Site.
Hope this helps.
Is this an intranet environment? If so they shouldn't have to login anyways. If sharepoint is setup using "Integrated Authentication" and the site is listed as a trusted site in IE, the browser will use there network cred for auto login. This can be setup on firefox as well.
Your users will not be able to connect to the NTLM site directly without getting an NTLM challenge. I would write what would effectively be a proxy to the NTLM site; i.e your server-side code will have credentials to connect to the NTLM site, and it passes through the requests from your users.
As you mention it's SharePoint (spit) bear in mind that SharePoint has a bunch of Web Services you could use for this (rather than doing screen-scraping).