search

darrenjrobinson / powershell_module_identitynow

SailPoint IdentityNow PowerShell Module
https://blog.darrenjrobinson.com/sailpoint-identitynow/
MIT License
47 stars 15 forks source link

update profile mapping, get auth, and get account #18

Closed 410sean closed 4 years ago

410sean commented 4 years ago

new update identity profile mapping one mapping at a time get-auth function for generating v2 or v3 key in future functions we can reduce repeat code

update get accounts, if api gateway has a timeout we do not lose everything, it will wait and repeat.

410sean commented 4 years ago

i wrote some additional changes which i see added to this pull request, i did want to get your feedback on the last two commits but maybe not commit them yet. the profile mapping stuff is good to go but the auth changes i would like some feedback on what to keep or change. for auth

  1. check the jwt details (borrowed your code from another module)
  2. if it is not within 1 minute of expired and a $ForceRefresh was not explicit it will return the saved jwt
  3. if there is no JWT or the JWT is expired it will try grant types in order, refresh token, client_credentials, then the recently ended support password so it would not break existing users of this module

i guess is personal access token the right way to push people? i haven't fully tested but just going off of scripts and programs section of this article https://community.sailpoint.com/t5/IdentityNow-Wiki/Best-Practices-IdentityNow-REST-API-Authentication/ta-p/79566

darrenjrobinson commented 4 years ago

Definitely looks like Personal Access Tokens is the way to start moving forward. The question is, will all cmdlets work using client credentials from a Personal Access Token?

If the client credential grant flow uses client credentials derived from a Personal Access Token, there will be a user context. - i.e., access request or administrative APIs should be available to the API caller.

And vice versa for client credentials from an oAuth Client

If the client credential grant flow uses client credentials derived from the OAuth 2.0 Client, there will not be a user context, only an API context. - i.e., access request or administrative APIs may not be available to the API caller.

Certain cmdlets may need to be called using the Client Credential Grant Flow with creds derived from a Personal Access Token with the majority defaulting to the Client Credential Grant Flow with creds derived from an oAuth Client.

darrenjrobinson commented 4 years ago

Waiting on a Code Signing Cert that I hope to have this week to sign the v1.0.8 release. Any updates on this PR @410sean ??

410sean commented 4 years ago

my branch called auth function seems to work ok (not what is in this pull request). this week i'll check for missed commits and resubmit the pull request