| I’ll leave a meta-comment here in the email thread and then comments about the options in the PR.
I think we should have a set of reference deployment architectures that we can use when defining standards and flows. I’ve definitely seen the deployment architecture Karl highlights, but I’ve also seen cases where the primary access point is an Authorization Server that then delegates to multiple IDPs and ASs within the enterprise. This can be helpful in scenarios where there is a lot of B2B and B2E related traffic to resources. This might mean the API Gateway and AS are combined into a single entity or the API Gateway may act as a “router” depending on the request.
I do think the concept of separating the Authorization Server from the IDP is an interesting one and it would be good to understand the implications of that deployment architecture.
I’m sure that Research & Education deployments are different from those described above.
Do others on this thread have other deployment architectures that should be considered as we work on these standards?
Thanks, George -- George Fletcher Practical Identity LLC Hi all, I would love to know what everyone thinks too. I am wholeheartedly in support of option #2, which I think provides the most flexibility, wherein an IdP could be the ID-JAG issuer, or an independent service (e.g. an Enterprise Authorization Server) could be the ID-JAG issuer.
Thanks Karl, for sharing these options on the list. Please see the conversation in Aaron's PR for more context.
Atul Would love to get broader feedback as this is a pretty significant change to the spec and each option has its own side effects. The PR lists some for Option 2
The menu is currently
1) Allow ID Tokens to be used with Token Exchange for ID-JAG where the Enterprise Authorization Server isn't the issuer or the audience of the ID Token (uses a very broad definition of EAS as a component of the same system vs cross-domain). 2) Allow Access Tokens to be used with Token Exchange for ID-JAG instead of an ID Token where the audience of the Access Token is the Enterprise Authorization Server 3) Collapse the JAG to an cross-domain Access Token with an audience of the Resource AS vs a Resource Server since the Resource AS already needs to support a custom issuer and the claims between JAG and Access Token are similar with similar need for mappings/etc for cross-domain use cases.
Interested to hear your thoughts if there is another path or what option is preferred and why.
-Karl
Here's the PR I mentioned during the DPoP session on Friday.
This provides the option to split out the role of the server that issues the ID-JAG. There are still some details to work out, feel free to add additional thoughts in the PR.
I'd like to resolve this sooner than later if we do decide to add this option.
Hi Karl and Aaron, As discussed in Montreal, I'd love to preview Aaron's PR in this regard.
Thanks, Atul
Hi Atul,
The server / service that issues the ID-JAG doesn't need to be an IDP. It could just be an "Authorization Management Platform" (as Gartner has recently named these things). The AMP is not really in the business of authenticating users, it only provides a way for organizations to define and enforce policies.
The IdP is already a Policy Enforcement Point (PEP) for Zero-Trust Policy for the enterprise. ID Tokens already commingle some authorization concerns and may include claims used for RP authorization (e.g. roles, groups, etc). Many Enterprise IdPs are often OAuth 2.0 Authorization Servers for Resource Servers managed by the enterprise and have centralized client & resource lifecycle management with access policies. IdPs in practice are not just authenticating users for SSO but also granting access to clients to act on behalf of enterprise users. TL;DR I think the problem already exists today for SSO and API Access Management outcomes. This spec extends what the IdP is already doing for 1st party resources with API Access Management to 3rd party Authorization Server. If it was viable to issue an Access Token directly to the 3P Resource Server (e.g JWT Access Token Profile) in another trust domain then customers would just use their existing IdP/AS infrastructure for this.
This spec also isn't just vanilla service to service but more specifically when can a service act as an enterprise managed user to another service in another trust domain. It's a proxy for the resource owner role in OAuth 2.0. The IdP already understands the different trust domains for the resource applications, manages trust keys, and brokers access across the domains. It's a federation problem and not just an authentication problem.
I would expect customers that have invested in a "Authorization Management Platform" to push the IdP vendors to integrate with their AMP as a PDP vs trying to make it to an "Issuer". My understanding is this is what is being proposed by the OpenID AuthZen WG https://hackmd.io/@oidf-wg-authzen/idp-integration. This would address not just this use case but also the broader set of challenges with SSO and API Access Management.
-Karl
Hi Aaron, Thanks for the clarification. Please see my comments below: I wouldn't characterize it as "aligned", I am trying to find a compromise.
Understood. I appreciate your flexibility.
I don't think you have the steps quite right. Assuming you are referring to the steps in Section 4.1, then the steps are:
Yes, those are the steps I was referring to.
> 1. User authenticates with the IdP Authorization Server, the Client obtains an Identity Assertion.
Yes, this requires that the client uses the IdP's token endpoint when using the authorization code flow. Nothing is changed compared with standard OpenID Connect in this draft with this step of the flow. It arguably shouldn't even be mentioned in the draft, but early feedback we got was that it was confusing to not mention it because it wasn't clear where the identity assertion came from otherwise.
I would be in favor of leaving this out, since nothing really changes about this part.
> 2. Client uses the Identity Assertion to request an Identity Assertion JWT Authorization Grant for the Resource Authorization Server from the IdP Authorization Server
This is the step that could be rephrased to "...from the ID-JAG endpoint" or some such, so that you have the carve-out to be able to run this on a separate server from the IdP.
This would work. I'm just a bit concerned though that the AS metadata is used to specify the ID-JAG authorization endpoint. As long as that part is kept optional (i.e. A client MAY discover the ID-JAG endpoint using the AS metadata), I'm good with this proposal.
Again, I don't actually think this is a good idea for the reasons mentioned in this thread above. Like George said, it's really a stretch to define this other ID-JAG-issuing service to be in the same domain that is able to validate ID tokens that have the audience of the IdP that's from a separate domain. Technically if you squint hard enough you can justify it, but it's really a stretch.
I would have to disagree here, since I am seeing a number of enterprises adopt authorization servers that are completely independent of the IdP. I feel that to arrive at consensus, we can just use your proposal above of separating the ID-JAG authorization endpoint.
Stepping back, it sounds like what you are actually trying to ask for is the ability to have the policies enabled by this flow run on an IdP that is different from where the actual user accounts live.
You are kind of right, except I'm trying to separate the part that issues the ID-Token, which I'm calling the authentication flow, from the part that issues the ID-JAG, which I'm calling the authorization flow. The server / service that issues the ID-JAG doesn't need to be an IDP. It could just be an "Authorization Management Platform" (as Gartner has recently named these things). The AMP is not really in the business of authenticating users, it only provides a way for organizations to define and enforce policies. I would say the better solution to that is to keep the clients requesting the ID Token and ID-JAG from the same IdP, but that IdP actually federates user authentication to another IdP. The other IdP would be unaware of the ID-JAG flow entirely, as it would only be responsible for user authentication. That seems like a totally valid architecture, and a way to roll this out in an enterprise that is using an IdP that doesn't support this new flow.
Based on my answer above, this does not really apply in my line of thinking.
Hi Aaron, It's great that we are aligned on the fact that the ID-JAG Authorization Server can be separate from the ID-Token Issuer.
However the change you are proposing, i.e. the AS metadata can point to two totally different URLs for the token endpoint and the authorization endpoint, is still limited as follows:
In Step 1 of the draft, the result of the exchange is an ID-Token, which (if using the code flow) involves using the IDP's token endpoint. This will need to be the IdP's own token endpoint, whereas the functionality required for the token exchange in step 2 of the draft is totally different. That requires the server to authorize the use of that ID-Token for a specific application.
I think this is the same question as "can't your token endpoint be on a different system than your authorization endpoint?"
The answer is technically yes, because how the token endpoint validates authorization codes isn't needed to be described in the spec because it's an implementation detail. What enables the possibility of that split is an explicit definition of both endpoints in the AS metadata. So the AS metadata can point to two totally different URLs for the two.
So the equivalent for this draft would be possible without any spec changes if the endpoint that issues the ID-JAG were called out as a separate endpoint in the AS metadata, instead of the current definition which is that it's the same token endpoint. How this theoretical separate system validates the ID token And maps user IDs would be out of scope.
I'm not sure I actually like this idea but it would at least enable the possibility.
Hi Karl, My comments below.
Thank you for your patience with my suggestions and questions, Atul A couple of other points to add - The ID-JAG has the same `iss`+`sub` as the SSO ID Token for the Resource Authorization Server as RP.
I'm not sure the ID-JAG is required to have the same `iss` or the same `sub` as the ID-Token. Perhaps the resource authorization server uses a separate identifier format and value for users than the IdP, and the ID-JAG Authorization Server (which in my proposal is separate from the IdP) does that mapping before it issues the ID-JAG. The resource authorization server can be configured to trust the ID-JAG Authorization Server instead of the IdP for the ID-JAG. - This ensures the same account linking/resolution logic for SSO can be reused for ID-JAG processing reducing surface area and security issues of generic claims mappings needed for something like vanilla JWT Authorization Grant in a federation. For example, the Resource Authorization Server as RP stores the IdP's iss+sub during JIT from SSO then matches the `iss`+`sub in the ID-JAG.
It's an architectural question for organizations about how the IdP issued identifiers should be mapped to the identifiers that the application recognizes. So if we are able to propose a standard that doesn't preclude the possibility that there may be a separate authorization server, then it makes the standard more valuable.
I think there is sufficient evidence that many large organizations choose to have separation between the authenticating party and the authorizing party, so as a standards body, we should permit and encourage both possibilities.
- The Resource Authorization Server can trust multiple IdPs and therefore multiple ID-JAG issuers (assuming the secure account resolution of multiple federation identifiers)
I'm not sure if it matters whether the party that a resource authorization server trusts for an ID-JAG is a combined "ID Token Issuer + Authorization Server", or just an "Authorization Server". Am I missing something?
I think the issue is that the id_token “audience” restrictions require them to be the same. Otherwise the “IdP Authorization Server” (that didn’t issue the id_token) would need to reject the id_token when received because the “audience” wouldn’t match. I’m not crazy about the idea that says a bunch of different services performing different tasks are still all the same “audience”.
George Fletcher Identity Standards Architect Practical Identity LLC
Hi Jeff, I'm not thinking of changing anything in the draft (e.g. using Transaction Tokens, WITs etc.) I'm only suggesting that we should not assume that the IdP that issued the ID-Token is the same as the "IdP Authorization Server" that issues the ID-JAG.
Atul
Not going against anything Aaron said, is your question
@Atul Tulshibagwale
cause you are thinking ahead of:
1/ A transaction Token could be exchanged for a ID-JAG?
2/ A Workload Identity Token could be exchanged for an ID-JAG? Jeff
Jean-François “Jeff” Lombardo |
Amazon Web Services Architecte Principal de Solutions, Spécialiste de Sécurité
Principal Solution Architect, Security Specialist
Montréal, Canada
Commentaires à propos de notre échange?
Exprimez-vous
ici. Thoughts on our interaction? Provide feedback
here.
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless
you can confirm the sender and know the content is safe.
|
AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne cliquez sur aucun lien et n’ouvrez
aucune pièce jointe si vous ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le contenu ne présente aucun risque.
|
For some background, the reason for this draft and the ID-JAG in the first place is to enable an Authorization Server to issue its own access tokens in response to a cross-domain artifact. This is better than the other two alternatives
which would be:
1. Client sends the IdP-issued ID Token to the Authorization Server in the other domain (violates ID Token "audience" policy processing)
2. Have the IdP issue an access token that the Resource Server in the other domain accepts (no protocol violation, but experience has shown Resource Server implementers do not want this)
Now to your actual question, why not enable the ID-JAG issuer to be separate from the ID Token issuer. This would also violate the ID Token "audience" processing, since the ID Token would be presented to an entity different from the issuer
of the ID Token.
Hi all,
Great to see the "Identity Assertion JWT Authorization Grant" proposal being accepted by OAuth. I'd like to propose that we
should not assume that the issuer of the ID-Token is the same as the issuer of the ID-JAG. There doesn't seem to be any reason provided for this either in the draft or in the short discussion we had today.
It's just something that is assumed in the draft, and I feel that can be generalized without affecting anything in the draft.
To address Aaron's response that "if you want them separate, then you return to the ID-Chaining draft": I feel there's a lot of value in this (ID-JAG) specification, and being able to apply to more use cases broadens the value of this specification.
I'd love to know what could be potential issues if the ID-JAG issuer is not assumed to be the same as the ID-Token issuer.
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to
[email protected]
_______________________________________________ OAuth mailing list -- [email protected]To unsubscribe send an email to [email protected]
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
|
