The maximum length of the UserName value is 513 characters.

[timbrigham]

I'm testing out using this module once installed using Install-SrfBuild and I'm getting the following:

PS C:\Windows\system32> $Alarm = Get-LrAieDrilldown -AlarmId $AlarmID
Get-LrAieDrilldown : Cannot process argument transformation on parameter 'Credential'. The maximum length of the UserName value is 513 characters.
At line:1 char:10
+ $Alarm = Get-LrAieDrilldown -AlarmId $AlarmID
+          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidData: (:) [Get-LrAieDrilldown], ParameterBindingArgumentTransformationException
    + FullyQualifiedErrorId : ParameterArgumentTransformationError,Get-LrAieDrilldown

This happens for any of the commands I've tried, including Get-LrTags. I'm not sure if I'm doing something wrong here or if this is actually a bug.

[timbrigham]

I did a little more digging here. Looks like .\New-TestBuild.ps1 creates the credential token correctly:

PS C:\SRP\SmartResponse-Framework_Editing> $SrfPreferences.LrDeployment.LrApiToken.GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     PSCredential                             System.Object

Whereas if I check that variable after Install-SrfBuild it comes back as a string:

PS C:\Windows\system32> $SrfPreferences.LrDeployment.LrApiToken.GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     String                                   System.Object

[timbrigham]

Found a workaround for my testing.. Edited this into SmartResponse.Framework.psm1

$password_as_stdstring = $SrfPreferences.LrDeployment.LrApiToken 
$token = ConvertTo-SecureString $password_as_stdstring
$mycreds = New-Object System.Management.Automation.PSCredential ("lr", $token)
$SrfPreferences.LrDeployment.LrApiToken = $mycreds

[Jt3kt]

Hey @timbrigham, I noticed this as well. Your workaround is similar to what I was looking at for the short term.

One of the approaches is to leverage a password vault and retrieve the API key through a cmdlet call. Today that's primarily Thycotic Secret Server, but I think expanding support to other vaults would be cool.

I was planning on exploring integration with https://github.com/hashicorp/vault.

Certainly should be a topic to discuss to find the best functionality while maintaining security.

[GeneCupstid]

Thanks @Jt3kt .

@timbrigham - the New-TestBuild script includes a convenience of loading a token by default that I did not include in the "real" module.

There are a lot of ways to go about storing and accessing the API Token, and I didn't want to dictate how that should work within the module (without more input from the community, anyway). It needs to be a PSCredential, but how you get or load that isn't defined by the module itself.

For now, its up to the user to either:

1. Supply a PSCredential object via the Credential parameter of cmdlets (each time one is called), or
2. Set the value of $SrfPreferences.LrDeployment.LrApiToken for that session to a PSCredential that contains the API key in the password field.

I include the following in my Smart Response Scripts to get the token and set it:

# after parameters, etc ...
Import-Module SmartResponse.Framework
$SrfPreferences.LrDeployment.LrApiToken = Get-Secret -SecretId 99999
# rest of the Smart Response...

Getting the API token from a vault at run time is probably the optimal method from a security perspective, but not everyone will have X brand of vault. So saving a credential with Export-CliXml certainly works as well, and is the most convenient method if a vault is unavailable. Should that functionality be built into the module, and how so?

We could assume that most users will use a saved credential, and add a path to one in the configuration file - but it will be important that the user that creates the credential xml is the same user that uses this module. That could a problem if you use one account to run the module interactively, and another for SRP... unless you do manual imports / use the test script for adhoc use. You can see how this starts to spiral a bit into more questions. They aren't difficult from a technical perspective, but I figured that there would be opinions about this, and wanted to get input from the community. :)

Sidenote: The value of $SrfPreferences.LrDeployment.LrApiToken is always expected to be a PSCredential, but if not specifically set, will appear as a System.String by default. I've opened an issue - cmdlets should inform the user if $SrfPreferences.LrDeployment.LrApiToken is missing or improperly typed.

[GeneCupstid]

I should note that Get-Secret is included with this module, but only supports Thycotic Secret Server. Jt3kt is considering adding support for HashiCorp, and there are plenty of other solutions out there as well... which again raises the question of how to handle the API token within the module.

We could even ditch the PSCredential and go with a secure string, but creating secure strings is more user friendly with Import/Export CliXml and PSCredentials (I think) - not to mention it adds an extra layer of obfuscation - which is all secure strings have to offer in the first place.

In fact, the shortcomings with secure strings is why I originally intended the token to only be set at run time in the first place - hopefully supplied by a vault, and not from a local file. Then we are only talking about memory, for the lifetime of an SRP.

[timbrigham]

Thanks @GeneCupstid. I get where you are coming from for securing the API token. I've actually been working on localizing another project that used a single secure string across multiple users and bombing out as a result.

As far as I'm concerned creating / importing the token could be totally outsourced from this module as long as you have the error handling in place. At most a little documentation stating it needs to be set before use, and a potential example case or two.

[GeneCupstid]

Agree on the documentation, and info to the user. At present its not at all user friendly or intuitive. The next change I'm adding will address this!

[GeneCupstid]

For follow up, see https://github.com/SmartResponse-Framework/SmartResponse.Framework/issues/10

Closing this issue in favor of fixes for documentation / token handling