FCLI SSC appversion create fails to --add-user

[rsenden]

(copied from other source)

I understand that using --copy-from does not copy the auth entities/access permissions from the source. Instead I believe we're directed to use the --add-users command option. However this option appears to fail to add users, despite the new application version being created successfully. Tracing the logs I see a 401 response that is silently ignored. I have created an fcli ssc session using a ci token, and all other actions appear to succeed.

This is from a session in fcli that i ssc session login as a CIToken that was created by an admin user. When I do a REST call directly to the api using the same token it works. For example:

curl 'https://ourssc/api/v1/projectVersions/10025/authEntities' \
-X 'PUT' \
-H 'Authorization: REDACTED-CIToken' \
-H 'accept: application/json' \
--data-raw '[{"id":17,"isLdap":false,"entityName":"someUser","displayName":"First Last","firstName":"First","lastName":"Last","type":"User","ldapDn":null,"userPhoto":null,"email":"someuser@company.com","_href":"https://ourssc/api/v1/authEntities/17"},{"id":5,"isLdap":false,"entityName":"user2","displayName":"User Second","firstName":"User","lastName":"Second","type":"User","ldapDn":null,"userPhoto":null,"email":null,"_href":"https://ourssc/api/v1/authEntities/5"}]'

[rsenden]

Hi,

Thanks for reporting this, some initial feedback below.

As for --copy-from not supporting copying access permissions, there's already a PR open for implementing this feature: https://github.com/fortify/fcli/pull/483. As for the 401 response that's silently being ignored, this is a known fcli issue: https://github.com/fortify/fcli/issues/476.

Lately we've been focusing on implementing some major new features (in particular the fcli * action commands) so haven't found time yet to address the PR & issue mentioned above. The 'copy auth permissions' PR author has been busy with other things and I'm waiting for feedback on whether this is fully ready to be merged. Hopefully one or both of these will be included in the near future, but no ETA yet.

As for why you're seeing a 401 error on the auth entities request, we'll need to do some research to see whether we can replicate this issue. As you mentioned that a plain curl command runs successfully, any chance you can try the same with the fcli ssc rest call command and let us know the results?

[rsenden]

I did some further research, conclusion is that SSC doesn't allow a CIToken to update application version auth entities (you can review allowed actions for CIToken in the SSC WEB-INF/internal/serviceContext.xml file).

Not sure why the curl command worked for you, I guess a UnifiedLoginToken or AutomationToken was mistakenly used during this test. Even with the SSC API Reference Swagger page, if I explicitly authenticate with a CIToken, SSC returns an authorization failure when trying to invoke the PUT /api/v1/projectVersions/<id>/authEntities endpoint. If I use a UnifiedLoginToken or AutomationToken, SSC successfully processes the same request.

So, to make this work with fcli, you'll need to pass either username/password, a UnifiedLoginToken or an AutomationToken to the fcli ssc session login command. Given that these tokens allow access to any REST endpoint, you may want to generate these from a user with restricted (non-administrative) role, especially if the token is shared across multiple people/teams. Using custom roles, you can define the exact permissions for that user (which may be a real or technical user), making it a safer approach for sharing a UnifiedLoginToken or AutomationToken with other people.

[rsenden]

For reference, even when copying an existing application version, fcli won't be able to copy user access settings if the fcli session was created using a CIToken. Request for updating CIToken permissions to allow updating user access settings has been shared with SSC product management, for now you'll need to use either an AutomationToken or UnifiedLoginToken.