What is the correct usage of New-PWLogin with the -Token argument?

If you've got Connection Client open and logged in then don't use either UserName or Token in the login.

$loginSplat = @{
  DatasourceName        = 'server:dsn'
  BentleyIMS            = $true
  NonAdminLogin         = $true
}
New-PWLogin @loginSplat

that should work

Thank you for your answer Kevin van Haaren I can 'make it work'
But my question is how to correctly login with New-PWLogin using the -Token argument.

For instance, should one specify the user name or not.
What constitutes a valid token in this case?
Are there other arguments of New-PWLogin (besides -Password and -UseGui) that are not compatible with -Token?
Etc.

Maybe you can also speculate on why it fails in my case.

And also why the -Token argument exists in the first place.

Thank you for your help.

This isn't the first unobvious mandatory switch pairing. Does PS/.NET allow for switches to be in mandatory definitions within parameter groups?

I realize it's hack-ish but could you assume -BenteyIMS if -Token supplied?

 MWBSI 

Get-PWConnectionClientToken -UsePWRelyingParty -verbose
seems to only work if the connection client is active, so not really fulfilling my goal.

Is there a way to get there from the token obtained with Get-OIDCToken?
Or are these unrelated tokens serving different purposes?
I appreciate your help but I'm still confused, sorry.

Once you get the token via the method above, you can re-use it.  However, you cannot bypass the Connection Client, at least initially.  This is by design.  

Presently you cannot use an OIDC token to log into ProjectWise.

Mark Weisman | Bentley Systems

MWBSI 

The token obtained with the method you suggest has a limited lifetime (a good thing).
But not compatible with my goal, unfortunately.

I was under the impression that the connection client could be bypassed using a standard OIDC token.
Not sure what purpose the Get-OIDCToken command serves then, if access tokens cannot be used.

Bill Graefe said:

This isn't the first unobvious mandatory switch pairing. Does PS/.NET allow for switches to be in mandatory definitions within parameter groups?

Yes, with parameter sets.

#region Parameters
[CmdletBinding(DefaultParameterSetName='Default')]
Param (
	[Parameter(
		ParameterSetName = 'Default',
		Position = 0,
		Mandatory,
		ValueFromPipeline,
		ValueFromPipelineByPropertyName,
		HelpMessage = 'Datasource name'
	)]
	[Parameter(
		Position = 0,
		ParameterSetName = 'Username',
		Mandatory,
		ValueFromPipeline,
		ValueFromPipelineByPropertyName,
		HelpMessage = 'Datasource name'
	)]
	[Parameter(
		Position = 0,
		ParameterSetName = 'BentleyIMS',
		Mandatory,
		ValueFromPipeline,
		ValueFromPipelineByPropertyName,
		HelpMessage = 'Datasource name'
	)]
	[String[]]$DatasourceName

	,[Parameter(
		ParameterSetName = 'Username',
		Mandatory,
		ValueFromPipelineByPropertyName,
		HelpMessage = 'Include inactive matching datasources'
	)]
	[String]$Username

	,[Parameter(
		ParameterSetName = 'Username',
		Mandatory,
		ValueFromPipelineByPropertyName,
		HelpMessage = 'Password'
	)]
	[SecureString]$Password

	,[Parameter(
		ParameterSetName = 'BentleyIMS',
		Mandatory,
		ValueFromPipelineByPropertyName,
		HelpMessage = 'Login with Bentley IMS'
	)]
	[Switch]$BentleyIMS

	,[Parameter(
		ParameterSetName = 'BentleyIMS',
		ValueFromPipelineByPropertyName,
		HelpMessage = 'Token'
	)]
	[String]$Token
)

That's approximately how it could work. That sets up 3 sets of parameters: Default, Username and BentleyIMS

DatasourceName is default in all 3 sets

Username/Password and mandatory but only in the Username set

BentleyIMS is mandatory in BentleyIMS set, but Token is optional

If you try to specify options that are mandatory in two or more sets you will get an error. If you specify a parameters that are in different sets, you will get an error (-Username -Token would be an error).

Specifying only the -DatasourceName would trigger the default set and it would attempt a SSO login using the current windows credentials

I left out handling -UseGUI, but that would probably be a 4th set.

Add in DoNotCreateWorkingDirectory, LoadWRE and NonAdminLogin as belonging to no set and they would be available as options in all sets.

Bill Graefe said:

This isn't the first unobvious mandatory switch pairing. Does PS/.NET allow for switches to be in mandatory definitions within parameter groups?

Yes, with parameter sets.

#region Parameters
[CmdletBinding(DefaultParameterSetName='Default')]
Param (
	[Parameter(
		ParameterSetName = 'Default',
		Position = 0,
		Mandatory,
		ValueFromPipeline,
		ValueFromPipelineByPropertyName,
		HelpMessage = 'Datasource name'
	)]
	[Parameter(
		Position = 0,
		ParameterSetName = 'Username',
		Mandatory,
		ValueFromPipeline,
		ValueFromPipelineByPropertyName,
		HelpMessage = 'Datasource name'
	)]
	[Parameter(
		Position = 0,
		ParameterSetName = 'BentleyIMS',
		Mandatory,
		ValueFromPipeline,
		ValueFromPipelineByPropertyName,
		HelpMessage = 'Datasource name'
	)]
	[String[]]$DatasourceName

	,[Parameter(
		ParameterSetName = 'Username',
		Mandatory,
		ValueFromPipelineByPropertyName,
		HelpMessage = 'Include inactive matching datasources'
	)]
	[String]$Username

	,[Parameter(
		ParameterSetName = 'Username',
		Mandatory,
		ValueFromPipelineByPropertyName,
		HelpMessage = 'Password'
	)]
	[SecureString]$Password

	,[Parameter(
		ParameterSetName = 'BentleyIMS',
		Mandatory,
		ValueFromPipelineByPropertyName,
		HelpMessage = 'Login with Bentley IMS'
	)]
	[Switch]$BentleyIMS

	,[Parameter(
		ParameterSetName = 'BentleyIMS',
		ValueFromPipelineByPropertyName,
		HelpMessage = 'Token'
	)]
	[String]$Token
)

That's approximately how it could work. That sets up 3 sets of parameters: Default, Username and BentleyIMS

DatasourceName is default in all 3 sets

Username/Password and mandatory but only in the Username set

BentleyIMS is mandatory in BentleyIMS set, but Token is optional

If you try to specify options that are mandatory in two or more sets you will get an error. If you specify a parameters that are in different sets, you will get an error (-Username -Token would be an error).

Specifying only the -DatasourceName would trigger the default set and it would attempt a SSO login using the current windows credentials

I left out handling -UseGUI, but that would probably be a 4th set.

Add in DoNotCreateWorkingDirectory, LoadWRE and NonAdminLogin as belonging to no set and they would be available as options in all sets.