11 KiB
- 2021-W05
2021-W05
2021-02-01 Monday
IN-PROGRESS enforce whoami db check to sync users. work
CLOCK: [2021-02-01 Mon 17:19]–[2021-02-01 Mon 18:19] => 1:00
[2021-02-01 Mon 17:19]
DONE fix iroh-auth doc regarding jwks work
CLOCK: [2021-02-01 Mon 10:35]–[2021-02-01 Mon 14:53] => 4:18
[2021-02-01 Mon 10:35]
2021-02-02 Tuesday
IN-PROGRESS Testing CSA Migration work
CLOCK: [2021-02-02 Tue 10:42]–[2021-02-03 Wed 10:11] => 23:29
[2021-02-02 Tue 10:42]
DONE morning routine work
CLOCK: [2021-02-02 Tue 09:48]–[2021-02-02 Tue 10:42] => 0:54
[2021-02-02 Tue 09:48]
2021-02-03 Wednesday
IN-PROGRESS CORS headers bug work
CLOCK: [2021-02-03 Wed 14:42]–[2021-02-04 Thu 10:24] => 19:42
[2021-02-03 Wed 14:42]
- ref
DONE IdP Migration Testing work
CLOCK: [2021-02-03 Wed 10:11]–[2021-02-03 Wed 10:11] => 0:00
[2021-02-03 Wed 10:11]
Note quite complex workflow but worked as expected. Had the "You are in the middle of an Invitation" prompt.
2021-02-04 Thursday
| Timestamp | Tags | Headline | Time | |||
|---|---|---|---|---|---|---|
| Total time | 9:46 | |||||
| 2021-02-04 Thursday | 9:46 | |||||
| [2021-02-04 Thu 17:32] | work, meeting | didi Posture | 1:28 | |||
| [2021-02-04 Thu 10:25] | work, review | morning review tour | 7:07 | |||
| [2021-02-04 Thu 10:24] | work | test and discussion about CSA… | 1:11 |
MEETING didi Posture work meeting
CLOCK: [2021-02-04 Thu 17:32]–[2021-02-04 Thu 19:00] => 1:28
[2021-02-04 Thu 17:32]
Best user experience, etc..
Create a response issue about OAuth2/OIDC/trusted clients.
{
"scopes": [
"openid","profile"
],
"description": "string",
"redirects": [
"https://127.0.0.1:5443/callback"
],
"availability": "everyone",
"name": "int-posture-test",
"grants": [
"auth-code"
],
"audiences": [
"posture"
]
}REVIEW morning review tour work review
CLOCK: [2021-02-04 Thu 10:25]–[2021-02-04 Thu 17:32] => 7:07
[2021-02-04 Thu 10:25]
DONE test and discussion about CSA Migration work
CLOCK: [2021-02-04 Thu 09:14]–[2021-02-04 Thu 10:25] => 1:11
[2021-02-04 Thu 10:24]
2021-02-05 Friday
| Timestamp | Tags | Headline | Time | |||
|---|---|---|---|---|---|---|
| Total time | 2:59 | |||||
| 2021-02-05 Friday | 2:59 | |||||
| work, chat | Team discussion | 0:36 | ||||
| [2021-02-05 Fri 11:34] | work, review | Ambrose review | 0:28 | |||
| [2021-02-05 Fri 09:49] | work, chat | Client creation review with Diana | 1:55 |
IN-PROGRESS playing? work
CLOCK: [2021-02-05 Fri 13:57]–[2021-02-05 Fri 14:57] => 1:00
[2021-02-05 Fri 13:57]
- ref
- Ambrose review
CHAT Team discussion work chat
CLOCK: [2021-02-05 Fri 11:42]–[2021-02-05 Fri 12:18] => 0:36
REVIEW Ambrose review work review
CLOCK: [2021-02-05 Fri 11:14]–[2021-02-05 Fri 11:42] => 0:28
[2021-02-05 Fri 11:34]
CHAT Client creation review with Diana work chat
CLOCK: [2021-02-05 Fri 09:19]–[2021-02-05 Fri 11:14] => 1:55
[2021-02-05 Fri 09:49]
Hi Diana,
Thanks for reaching out.
While reviewing the doc, I also checked the second screenshot. I think it should be changed by another one. The screenshot was made by a super user, so the scopes displayed are private one that none of our customer will ever see.
The main difference between a "Client Credentials Grant Client" and an "Authorization Code Grant Client" (those are the technically correct and kind of bad names for the two different kind of clients) is that:
- Client Credentials Grant Client are for your user only. Also you do not need to own a website.
- Authorization Code Grant Client can be used to ask other users to trust your application. You need to have a website to host your application.
The reason why a customer would want to configure an Authorization Code Grant Client could be:
- The customer follow a documentation provided by Cisco to integrate a on-premise product. In that case, the customer will probably need to only select a client-preset and enter a custom Redirect URL.
- The customer want to build an integration with SecureX. In this case this will be an advanced usage and the creator will probably be a developer. In this case the advanced developer doc should be mentionned for that customer. https://visibility.amp.cisco.com/iroh/doc/iroh-auth/
So both kind of clients are sufficiently different that I think the section about "Using API Client Credentials to Get Access Token" should be moved just after the API client creation section and before OAuth Code client creation section.
Also Explaining how to retrieve the access token from a Authorization Code Grant client is quite a technically advanced topic. This is why I would advise to directly provide a link to the advanced developer doc (the one inside IROH not the Cisco DEVNET; thus https://visibility.amp.cisco.com/iroh/doc/iroh-auth/)
So I think it is important to mention important limitations about those client creations. There is a notion of "Auto-approved clients". So a customer will be able to create clients but if some criteria are not met the client will be disabled until an IROH admin approve the client.
I think this should probably need to be talked about with someone in the UI/UX team. This system was very convenient for our advanced usage, but I don't know how to handle that nicely in the UI.
So here are (some) of the constraints a newly client must have to be automatically approved:
- The URL must start with
https:// - The URL must not contain any wildcard
* - The Availabily must not be
everyone - The client contain some restricted scope (this should never occurs as the UI take care to show only scopes not subject to restriction)
- The client must not be
public(the UI does not appear to provide the confidential vs public option) - The client configure a list of specific
audiences(the UI does not appear to provide any mean to configure this field)
I think for the documentation perspective we should only be concerned by point 1, 2 and 3. And this should probably be mentionned. I think we could probably give a few hints. So in your point 6
> Enter the Redirect URL that the authorization server uses to redirect back to the application. > Click Add another Redirect URL to enter multiple URLs.
I think you should probably mention that all URL must start with https://
and should not contain any *.
And for point 7
> Choose the Availability from the drop-down list. You can make the client > available to User, Organization, or Everyone.
You should probably mention that selecting Everyone is subject to approval and will need the intervention of a Cisco Administrator to approve your client.
We should probably add a short sentence explaining what is Availbility for. This is not an OAuth2 standard field. Availabilty "Org" mean that only member of your own Organization will be able to approve your client and this should probably be your default choice.
I hope I have been helpful. Do not hesitate to reach out if you have more questions.