The key error appears to be mapping a Java Enum value to a value in XML config file.
java.lang.IllegalArgumentException: No enum const class com.salesforce.dataloader.action.OperationInfo. at java.lang.Enum.valueOf(Unknown Source)
Specifically the OperationInfo enum.
Having had a peak into this Enum I can see it requires the following values...
insert,
update,
upsert,
delete,
hard_delete,
extract,
extract_all
Since Java is case senstiive by default, the following part of your config will need to change to using a value from the above....
<entry key="process.operation" value="extract"/>
The Salesforce documentation gives one example of this in this topic Data Loader Process Configuration Parameters.
However the linked topic, Data Loader Command Line Operations, gives only the labels of these values and not the actual config values needed, which I agree is confusing and misleading in the context from which the page was linked. Hopefully the above list gives future readers the mapping they need! :)
Generally, authentication to salesforce always requires at least username,password (the example you provide above is using single sign on, via oAuth, which in this case uses username and password in a salesforce login page). Tying auth to a user ensures that the sf Admin can control user profile settings, and object access.
Generally, only when using some kind of JWT token within an SSO process (JWT is not supported by dataloader), can you skip password.
(for a broader understanding of how many different ways auth is possible in single sign on scenerios, see this help file: https://help.salesforce.com/articleView?id=remoteaccess_oauth_flows.htm&type=5)
However, Dataloader requires username password.
Dataloader also offers username/password encryption options.
Will that help you meet your business requirements (perhaps security is your concern?)
https://help.salesforce.com/articleView?id=loader_encryption.htm&type=5
You could also use a different tool which supports a different kind of auth.
This could be a good lead: since SFDX support oAuth, as well as subsequent alls without storing the username/password, try looking into the SFDX force:data CLI commands...
https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_force_data.htm
Here is a related post:
Can I use SalesforceDX to load data into sandboxes?
Best Answer
NOTE: All of these answers depend on the OOTB functionality. It is possible to adapt the Data Loader to perform all of these actions by using Java and importing the classes; this isn't an answer that covers that in-depth. There is an OSS version of ADL on GitHub, if you're so inclined.
No, SAML requires browser interaction, which isn't built into the Data Loader.
Yes, DA is implemented on the server end, so as long as the user's enabled for DA, their password will be verified by the web service.
Yes, OOTB parameters are ignored for GUI invocations, at least as far as the documentation is concerned; while you could probably default the username, the password is apparently non-optional.
No, you need browser interaction for SAML, so the same rules apply as the GUI here.
As for GUI, yes.
You can use name=value parameters, so you could supply a username and password via a batch file or script. However, the password must be encrypted, so some extra steps would have to be taken to encrypt the password before attempting this method. Supplying the values by command line is the same as placing the values in the config file, but won't be stored to disk.