Split IdP and Enterprise Authorization Server roles #64
Conversation
|
For completeness sake, here is a diagram showing how this would look when the IdP and EAS are combined, we get to use the refresh token as an optimization. 
And here is the version where the client first does SAML for SSO. It needs to first exchange the SAML assertion for an Access Token. 
|
There was a problem hiding this comment.
We should define the pros and cons of this approach. Here are some I can think of
Pro
- IdP doesn't have to natively support ID-JAG enabling adoption of ID-JAG outside of IdP as the Resource AS can trust different issuers
- Another enterprise system can provide an authorization capability enabling best of breed for enterprise
- Resource AS could trust multiple ID-JAG issuers for the Enterprise without complicating or changing IdP configuration for SSO
Con
- Introduces need to explain and manage/control how both issuers are part of the same trust domain and this doesn't introduce a 3rd trust domain for identity chaining. The EAS can effectively perform an on-behalf-of for an IdP identity for a downstream resource without the IdP knowing what resource (no constrained delegation).
- More complicated discovery for Client to know how to get an ID-JAG
- Resource AS may need to support more complex claims mapping that could add more security surface area to attack. It can't assume its the IdP and keep same account resolution logic used for SSO (e.g different issuers for example).
- More ambiguity on how this is different than Vanilla JWT Authorization Grant
- Exchanging an Access Token for an ID-JAG that looks like an Access Token just with different type for yet another Access Token adds cognitive overhead and will create confusion on why not just use the original Access Token as grant and bypass all the additional layers of abstraction. The audience of an access token for a resource indicator request could be the EAS or the Resource AS for example.
- Introduces need to profile the Access Token for Token Exchange interoperability with Enterprise AS
- Access Token for Token Exchange may not contain necessary authentication context to make an authorization decision (e.g zero-trust) that was previously in IdP
| IdP | ||
| : A SAML 2.0 Identity Provider or OpenID Connect Provider (OP) {{OpenID.Core}} that issues Identity Assertions for single sign-on for a set of trusted applications in an organization's application ecosystem. In {{I-D.ietf-oauth-identity-chaining}}, this is the out-of-scope token issuer that issued the token used as the input to the Token Exchange request as described in Section 2.1. | ||
|
|
||
| Enterprise Authorization Server (EAS) |
There was a problem hiding this comment.
Might be useful to describe how IdP and Enterprise Authorization Server are in the same trust domain even though they could be different issuers such as components of the enterprise's identity management infrastructure provided by different vendors or systems
| The Identity Assertion JWT Authorization Grant (ID-JAG) is a profile of the JWT Authorization Grant {{RFC7523}} that grants a client delegated access to a resource in another trust domain on behalf of a user without a direct user-approval step at the authorization server. | ||
|
|
||
| An ID-JAG is issued and signed by an IdP Authorization Server similar to an ID Token {{OpenID.Core}}, and contains claims about an End-User. Instead of being issued for a client (Relying Party in {{OpenID.Core}}) as the intended audience for the assertion, it is instead issued with an audience of an Authorization Server in another trust domain (Resource Authorization Server). It replaces the need for the client to obtain an authorization code from the Resource Authorization Server to delegate access to the client, and instead uses the IdP Authorization Server which is trusted by the Resource Authorization Server to delegate access to the client. | ||
| An ID-JAG is issued and signed by an Enterprise Authorization Server similar to an ID Token {{OpenID.Core}}, and contains claims about an End-User. Instead of being issued for a client (Relying Party in {{OpenID.Core}}) as the intended audience for the assertion, it is instead issued with an audience of an Authorization Server in another trust domain (Resource Authorization Server). It replaces the need for the client to obtain an authorization code from the Resource Authorization Server to delegate access to the client, and instead uses the Enterprise Authorization Server which is trusted by the Resource Authorization Server to delegate access to the client. |
There was a problem hiding this comment.
Enterprise Authorization Server doesn't issue an ID Token. This needs to be modified for the split role as it no longer is constrained the same entity that issues an ID Token.
There was a problem hiding this comment.
That is true (EAS doesn't issue ID-Tokens), but the ID-JAG still has commonalities with the ID-Token, so I guess this text is OK.
There was a problem hiding this comment.
I don't see anything in this text that implies the ID token is issued by the Enterprise Authorization Server. "Similar to" just refers to the shape of an ID token.
There was a problem hiding this comment.
The "similar to" in "ID-JAG is issued and signed by an Enterprise Authorization Server similar to an ID Token" reads more like it's about issuance rather than the shape. And contrasting bits like "Instead of being issued for a client" are more of a stretch because the "instead of" is relative to an ID token that's not issued by this EAP.
|
|
||
| `sub`: | ||
| : REQUIRED - Subject Identifier. An identifier within the IdP Authorization Server for the End-User, which is intended to be consumed by the Client as defined in {{OpenID.Core}}. The identifier MUST be the same as the subject identifier used in an Identity Assertion for the Resource Authorization Server as a Relying Party for SSO. A public subject identifier MUST be unique when scoped with issuer (`iss`+`sub`) for a single-tenant issuer and MUST be unique when scoped with issuer and tenant (`iss`+`tenant`+`sub`) for multi-tenant issuer. See {{client-id-mapping}} for additional considerations. | ||
| : REQUIRED - Subject Identifier. An identifier within the IdP for the End-User, which is intended to be consumed by the Client as defined in {{OpenID.Core}}. The identifier MUST be the same as the subject identifier used in an Identity Assertion for the Resource Authorization Server as a Relying Party for SSO. A public subject identifier MUST be unique when scoped with issuer (`iss`+`sub`) for a single-tenant issuer and MUST be unique when scoped with issuer and tenant (`iss`+`tenant`+`sub`) for multi-tenant issuer. See {{client-id-mapping}} for additional considerations. |
There was a problem hiding this comment.
We will need to refresh this to explain how a different issuer can have the same identifier as an ID Token when ID Token guidance is iss+ sub for account resolution.
There was a problem hiding this comment.
We can just leave it unspecified, or say something like "the semantics of how an EAS issues the same identifiers as the IdP is outside the scope of this specification".
There was a problem hiding this comment.
Yeah in general I'd like to keep the EAS<->IdP communication and links out of scope. This is analogous to how the AS<->RS link is out of scope in core OAuth.
There was a problem hiding this comment.
The issue isn't EAS<->IdP communication, but rather how does the Resource AS identify the resource owner from the token. SSO to the Resource AS as a RP has account resolution mechanism already that needs to be modified to support split roles for ID-JAG processing. Previously it could ensure that the iss + sub of ID-JAG ==iss + sub of ID Token. They both has the same identifier scope. This is no longer the case. EAS may not be authoritative for every sub of the IdP. It can't just replace the ID Token iss with EAS iss when identifying the resource owner (assuming EAS has a mechanism to obtain the IdPs' sub). This is the cross-domain account resolution vulnerabilities this change introduces that I prefer we have don't leave to deployment. For example if aud_sub was required to identify the resource owner then ther is no ambiguity for account resolution as the scope of the identifier is always local to the Resource AS. I don't think its practical to require aud_sub, just illustrating the point.
There was a problem hiding this comment.
The RAS can do a mapping based on the issuer of the EAS iss claim and the IDP's original iss claim.
There was a problem hiding this comment.
I think maybe the point that @mcguinness is driving at here is that in the model currently in the draft that is "coordinating through a common enterprise identity provider" allows for some meaningful constraints and expectations on the content of the ID-JAG. And that those are lost when splitting the IDP into different things.
| ~~~ | ||
| {: #fig-sequence-diagram title="Identity Assertion JWT Authorization Grant Sequence" } | ||
|
|
||
| 1. User authenticates with the IdP, the Client obtains an Identity Assertion (e.g. OpenID Connect ID Token or SAML 2.0 Assertion) for the user, an Access Token, and optionally a Refresh Token (when using OpenID Connect) and signs the user in |
There was a problem hiding this comment.
Should indicate that the access token should be requested for Enterprise AS resource using resource indicator. It may be indicated by a scope as well (e.g. Entra)
| 4. Client makes an API request to the Resource Server with the Access Token | ||
|
|
||
| This specification is constrained to deployments where a set of Resource Authorization Servers for applications used by an organization are trusting the same IdP Authorization Server for Single Sign-On (SSO). The IdP Authorization Server provides a consistent trust boundary and user identity for the set of Resource Authorization Servers to honor the ID-JAG issued by the IdP. The Resource Authorization Server not only delegates user authentication but also delegates user authorization authority to the IdP Authorization Server for the scopes and resource specified in the ID-JAG and does not need obtain user consent directly from the resource owner. | ||
| This specification is constrained to deployments where a set of Resource Authorization Servers for applications used by an organization are trusting the same IdP for Single Sign-On (SSO), and the same Enterprise Authorization Server for authorization. The IdP provides a consistent trust boundary and user identity for the set of Resource Authorization Servers to honor the ID-JAG issued by the Enterprise Authorization Server. The Resource Authorization Server not only delegates user authentication but also delegates user authorization authority to the Enterprise Authorization Server for the scopes and resource specified in the ID-JAG and does not need obtain user consent directly from the resource owner. It is also possible for the Enterprise Authorization Server to be built into the IdP itself. |
There was a problem hiding this comment.
"same IdP for Single Sign-On (SSO), and the same Enterprise Authorization Server for authorization" doesn't make sense as worded with split roles
There was a problem hiding this comment.
Perhaps restate as: "Trusting an IdP for SSO and an EAS for ID-JAG issuance in the same trust domain. It is also possible for the EAS to be built into the IdP itself."
There was a problem hiding this comment.
I think the original text does actually make sense. This only works if all the resource apps do SSO to the IdP and process ID-JAGs from the same EASs.
| Location: https://acme.idp.example/authorize?response_type=code&scope=openid%20offline_access&client_id=... | ||
|
|
||
| The user authenticates with the IdP, and is redirected back to the Client with an authorization code, which it can then exchange for an ID Token and optionally a Refresh Token when `offline_access` scope is requested per {{OpenID.Core}}. | ||
| The user authenticates with the IdP, and is redirected back to the Client with an authorization code, which it can then exchange for an ID Token, Access Token, and optionally a Refresh Token when `offline_access` scope is requested per {{OpenID.Core}}. |
There was a problem hiding this comment.
See comment above about access token needed to be requested for a different resource than the IdP. This may cause challenges if RPs want to also use the access token to access UserInfo or other protected resources at the IdP (e.g. Graph API or some other discovery resource).
We also need to make some statement about scopes for the access token. Are we going to leave this to be implementation specific (e.g. Enterprise AS can trust whatever scopes it wants and the Client needs to know what magic scope to request) or scope standardized by this spec or there is a discovery mechanism for the Client to know what scope to request
There was a problem hiding this comment.
Agree with the aud concern in the Access Token.
It might be good to specify the scope that enables the EAS to issue ID-JAGs, but on the other hand, it could be left as an implementation concern.
There was a problem hiding this comment.
Given that OpenID Connect defines scopes used for SSO, it probably does make sense to define scopes for this.
It's actually the default to have multiple values in the aud claim, and I don't see anything wrong with issuing an access token that is accepted by the IdP for the userinfo endpoint and accepted by the EAS for this use.
There was a problem hiding this comment.
I'm OK with multiple audiences for access token just think this may need to be clear to reader as it puts some requirements on the IdP (e.g not all IdPs may support multiple audiences) that may affect client interoperability (when can I make a single authorization request vs when do I need to split them out).
| &client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer | ||
| &client_assertion=eyJhbGciOiJSUzI1NiIsImtpZCI6IjIyIn0... | ||
|
|
||
| ### Processing Rules |
There was a problem hiding this comment.
We will need to refresh the processing rules for an Access Token. We currently don't prescribe it must be a JWT or whether is must conform to the JWT Access Token profile.
The ID-JAG may contain authentication claims as it previously was exchanged from an ID Token. Authentication context now must travel via the Access Token.
There was a problem hiding this comment.
I agree, a JWT format access token should be prescribed (but not required).
There was a problem hiding this comment.
I'd say a strong reference to RFC9068 would be useful but by no means would I want to require that.
There was a problem hiding this comment.
true. Did you mean "strong reference" or "strong preference"?
There was a problem hiding this comment.
reference. I don't want to force anyone into a particular access token format.
| ## Token Exchange | ||
|
|
||
| The Client makes a Token Exchange {{RFC8693}} request to the IdP Authorization Server's Token Endpoint with the following parameters: | ||
| The Client makes a Token Exchange {{RFC8693}} request to the Enterprise Authorization Server's Token Endpoint with the following parameters: |
There was a problem hiding this comment.
How does the Client know about this endpoint? There currently isn't any metadata to discover it.
There was a problem hiding this comment.
It should be possible to include a field in the OPRM of the Resource Server that points to the token endpoint for the ID-JAG. This could either be the EAS, or it could be the IdP, depending upon the implementation. Alternatively, the OPRM of the Resource Server will point to the Resource Authorization Server, and the OPRM of that server (since it is acting as the resource that requires the ID-JAG for access) will point to the EAS? We probably need to specify this.
There was a problem hiding this comment.
No, this is not possible. The Protected Resource Metadata of the RS is a static file, but there may be multiple accepted ID-JAG issuers depending on the tenant. This would be like saying there is only one enterprise IdP tenant supported for the app for SSO.
There was a problem hiding this comment.
I guess there are two possible flows here:
- Client begins at IdP and knows which RS it wants to go to. There is no discovery issue here. If the IdP and EAS are separate, then the IdP needs to instruct the client about where to send the access token for issuing the ID-JAG. This could be configured in the client, or Karl's other draft could come in handy here, and it can be configured in the IdP.
- Client begins with knowing they want to access the RS, and needs to discover where to get the access token for it. It goes to the RAS (possibly through OPRM), and then the RAS has the same problem, where does it send the user to get an ID-JAG. This problem is no different from if there were multiple IdPs or multiple ID-JAG issuers (i.e., multiple EASes).
In the second flow, is there something unique about the situation where the EAS is separate from the IdP?
There was a problem hiding this comment.
- We would need a well known scope to request to add the EAS audience for the access token as the Client didn't ask the
resourceexplicitly along with https://www.ietf.org/archive/id/draft-mcguinness-oauth-resource-token-resp-00.html. This doesn't address the problem in 2 as it just says you have access to the EAS not what trusted RAS resources. - Discovery of what Resource Authorization Servers are trusted by an IdP is tracked in Discovering allowed Resource App (instances) for the logged in user #52. Discovery of whether a RAS accepts an ID-JAG was covered by Authorization Server Metadata to enable discovery of JWT Assertion Grant #34. The Client knew a user's IdP so could discover connected resources from the IdP just like SSO. I think the delta here was the assumption that resource owner for the RAS only belonged to as single IdP (e.g.
iss+sub) so if the RAS supported ID-JAG via metadata and the IdP support ID-JAG via metadata then the Client could attempt to obtain an ID-JAG from the IDP. They may not be authorized or the RAS not trusted which would be a runtime error hence need for a discovery call to enumerate whats allowed.
Discovery of what issuers a RAS trust would more than likely need to be an authenticated call (e.g. client assertion)
There was a problem hiding this comment.
I agree we need a well known scope that permits the issuance of ID-JAGs by the EAS.
I think the discovery question is separate from the issue being discussed in this PR (whether the IdP and ID-JAG issuer are the same), so we can discuss that separately.
| "grant_types_supported": [ | ||
| "authorization_code", "refresh_token", "urn:ietf:params:oauth:grant-type:token-exchange" | ||
| ], | ||
| "identity_chaining_requested_token_types_supported": ["urn:ietf:params:oauth:token-type:id-jag"], |
There was a problem hiding this comment.
Isn't this example where IdP and EAS are co-located?
|
|
||
| IdP Authorization Server (IdP) | ||
| : A SAML 2.0 Identity Provider or OpenID Connect Provider (OP) {{OpenID.Core}} that issues Identity Assertions for single sign-on and cross-domain authorization grants {{id-jag}} for a set of trusted applications in an organization's application ecosystem. In {{I-D.ietf-oauth-identity-chaining}}, this is the Authorization Server in trust domain A, which is also trusted by the Resource Authorization Server in trust domain B. | ||
| IdP |
There was a problem hiding this comment.
Does it make sense to still call this an IdP Authorization Server as it still needs to support OAuth2 token issuance for the access token to the EAS resource? Its not just vanilla OP or SAML IdP
There was a problem hiding this comment.
While what you are saying is true (it is issuing an Access Token to the EAS, therefore it is an authorization server), but it will get confusing if we have an "IdP Authorization Server" and an "Enterprise Authorization Server". We should reserve the use of "IdP Authorization Server" to be when the EAS and the IdP are combined into one function.
There was a problem hiding this comment.
The IDP MUST be an OAuth 2.0 Authorization Server and can’t be just a SAML IDP and the Client will need a client registration with the IdP to obtain the access token. These requirements needs to be clear even if we are choosing not to use the term IdP Authorization Server. There are many IdPs that don’t provide this capacity in the wild.
The Enterprise Authorization Server also doesn’t issue Access Tokens which is what an Authorization Server does in Oauth 2.0. We may be forcing the wrong terms here.
There was a problem hiding this comment.
Authorization Server doesn't have to mean an OAuth Authorization Server, so I think the terminology makes sense even though the EAS isn't issuing access tokens.
There was a problem hiding this comment.
The feedback we got from the first draft was introducing new roles that are different than the roles defined in OAuth 2.0 is confusing to the reader. This is an OAuth extension so should build on existing body of work and not redefine. We updated the spec to reflect this feedback. I am not keen on "Authorization Server doesn't have to mean an OAuth Authorization Server" for an OAuth spec.
| The Identity Assertion JWT Authorization Grant (ID-JAG) is a profile of the JWT Authorization Grant {{RFC7523}} that grants a client delegated access to a resource in another trust domain on behalf of a user without a direct user-approval step at the authorization server. | ||
|
|
||
| An ID-JAG is issued and signed by an IdP Authorization Server similar to an ID Token {{OpenID.Core}}, and contains claims about an End-User. Instead of being issued for a client (Relying Party in {{OpenID.Core}}) as the intended audience for the assertion, it is instead issued with an audience of an Authorization Server in another trust domain (Resource Authorization Server). It replaces the need for the client to obtain an authorization code from the Resource Authorization Server to delegate access to the client, and instead uses the IdP Authorization Server which is trusted by the Resource Authorization Server to delegate access to the client. | ||
| An ID-JAG is issued and signed by an Enterprise Authorization Server similar to an ID Token {{OpenID.Core}}, and contains claims about an End-User. Instead of being issued for a client (Relying Party in {{OpenID.Core}}) as the intended audience for the assertion, it is instead issued with an audience of an Authorization Server in another trust domain (Resource Authorization Server). It replaces the need for the client to obtain an authorization code from the Resource Authorization Server to delegate access to the client, and instead uses the Enterprise Authorization Server which is trusted by the Resource Authorization Server to delegate access to the client. |
There was a problem hiding this comment.
That is true (EAS doesn't issue ID-Tokens), but the ID-JAG still has commonalities with the ID-Token, so I guess this text is OK.
|
|
||
| `sub`: | ||
| : REQUIRED - Subject Identifier. An identifier within the IdP Authorization Server for the End-User, which is intended to be consumed by the Client as defined in {{OpenID.Core}}. The identifier MUST be the same as the subject identifier used in an Identity Assertion for the Resource Authorization Server as a Relying Party for SSO. A public subject identifier MUST be unique when scoped with issuer (`iss`+`sub`) for a single-tenant issuer and MUST be unique when scoped with issuer and tenant (`iss`+`tenant`+`sub`) for multi-tenant issuer. See {{client-id-mapping}} for additional considerations. | ||
| : REQUIRED - Subject Identifier. An identifier within the IdP for the End-User, which is intended to be consumed by the Client as defined in {{OpenID.Core}}. The identifier MUST be the same as the subject identifier used in an Identity Assertion for the Resource Authorization Server as a Relying Party for SSO. A public subject identifier MUST be unique when scoped with issuer (`iss`+`sub`) for a single-tenant issuer and MUST be unique when scoped with issuer and tenant (`iss`+`tenant`+`sub`) for multi-tenant issuer. See {{client-id-mapping}} for additional considerations. |
There was a problem hiding this comment.
We can just leave it unspecified, or say something like "the semantics of how an EAS issues the same identifiers as the IdP is outside the scope of this specification".
| 4. Client makes an API request to the Resource Server with the Access Token | ||
|
|
||
| This specification is constrained to deployments where a set of Resource Authorization Servers for applications used by an organization are trusting the same IdP Authorization Server for Single Sign-On (SSO). The IdP Authorization Server provides a consistent trust boundary and user identity for the set of Resource Authorization Servers to honor the ID-JAG issued by the IdP. The Resource Authorization Server not only delegates user authentication but also delegates user authorization authority to the IdP Authorization Server for the scopes and resource specified in the ID-JAG and does not need obtain user consent directly from the resource owner. | ||
| This specification is constrained to deployments where a set of Resource Authorization Servers for applications used by an organization are trusting the same IdP for Single Sign-On (SSO), and the same Enterprise Authorization Server for authorization. The IdP provides a consistent trust boundary and user identity for the set of Resource Authorization Servers to honor the ID-JAG issued by the Enterprise Authorization Server. The Resource Authorization Server not only delegates user authentication but also delegates user authorization authority to the Enterprise Authorization Server for the scopes and resource specified in the ID-JAG and does not need obtain user consent directly from the resource owner. It is also possible for the Enterprise Authorization Server to be built into the IdP itself. |
There was a problem hiding this comment.
Perhaps restate as: "Trusting an IdP for SSO and an EAS for ID-JAG issuance in the same trust domain. It is also possible for the EAS to be built into the IdP itself."
| Location: https://acme.idp.example/authorize?response_type=code&scope=openid%20offline_access&client_id=... | ||
|
|
||
| The user authenticates with the IdP, and is redirected back to the Client with an authorization code, which it can then exchange for an ID Token and optionally a Refresh Token when `offline_access` scope is requested per {{OpenID.Core}}. | ||
| The user authenticates with the IdP, and is redirected back to the Client with an authorization code, which it can then exchange for an ID Token, Access Token, and optionally a Refresh Token when `offline_access` scope is requested per {{OpenID.Core}}. |
There was a problem hiding this comment.
Agree with the aud concern in the Access Token.
It might be good to specify the scope that enables the EAS to issue ID-JAGs, but on the other hand, it could be left as an implementation concern.
| ## Token Exchange | ||
|
|
||
| The Client makes a Token Exchange {{RFC8693}} request to the IdP Authorization Server's Token Endpoint with the following parameters: | ||
| The Client makes a Token Exchange {{RFC8693}} request to the Enterprise Authorization Server's Token Endpoint with the following parameters: |
There was a problem hiding this comment.
It should be possible to include a field in the OPRM of the Resource Server that points to the token endpoint for the ID-JAG. This could either be the EAS, or it could be the IdP, depending upon the implementation. Alternatively, the OPRM of the Resource Server will point to the Resource Authorization Server, and the OPRM of that server (since it is acting as the resource that requires the ID-JAG for access) will point to the EAS? We probably need to specify this.
| &client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer | ||
| &client_assertion=eyJhbGciOiJSUzI1NiIsImtpZCI6IjIyIn0... | ||
|
|
||
| ### Processing Rules |
There was a problem hiding this comment.
I agree, a JWT format access token should be prescribed (but not required).
| * Resource Authorization Server to IdP Authorization Server (OpenID Connect or SAML) | ||
|
|
||
| Each relationship is typically represented by independent client registrations between each party. For example, the IdP Authorization Server typically issues a Client ID for both the Client and Resource Authorization Server to use for single sign-on with OpenID Connect as a Relying Party. Similarly, the Resource Authorization Server typically issues a Client ID for the Client to use for API access to the Resource Server. The Client may choose to use different client credentials with each registration. | ||
| Each relationship is typically represented by independent client registrations between each party. For example, the IdP Server typically issues a Client ID for both the Client and Resource Authorization Server to use for single sign-on with OpenID Connect as a Relying Party. Similarly, the Resource Authorization Server typically issues a Client ID for the Client to use for API access to the Resource Server. The Client may choose to use different client credentials with each registration. |
There was a problem hiding this comment.
In the revised picture, could the EAS issue the Client ID for the RAS? I suppose we should also mention this possibility?
There was a problem hiding this comment.
This text just includes examples. I don't think we need to add that as an example because it would be a relatively rare edge case. The case where that would be possible is if the Resource does not support SSO, but is configured to accept access tokens issued from ID-JAGs.
| * Client to IdP (OpenID Connect or SAML) | ||
| * Client to Enterprise Authorization Server (OAuth) | ||
| * Client to Resource Authorization Server (OAuth) | ||
| * Resource Authorization Server to IdP Authorization Server (OpenID Connect or SAML) |
There was a problem hiding this comment.
Change this line from IdP AS (OIDC or SAML) to Enterprise AS (ID-JAG) ? This isn't really vanilla OAuth or OIDC, right?
There was a problem hiding this comment.
No, this is correct. The IdP<->EAS relationship is not specified in this draft, it is neither OAuth nor OpenID Connect.
There was a problem hiding this comment.
We haven't used the term "IdP Authorization Server" anywhere post this PR, but this line still says "IdP Authorization Server". Is that to cover the case where the two are combined?
There was a problem hiding this comment.
Nope that was a mistake, I missed changing this one from "IdP Authorization Server" to "IdP". I just fixed it.
Not sure I understand this comment from Karl. Why does this matter to the RAS? If the EAS applies any business logic, it should be no different than what an IdP might do. Ideally, the EAS should be making it easier for the RAS to understand the ID-JAG, just like the an IdP would. |
| IdP Authorization Server (IdP) | ||
| : A SAML 2.0 Identity Provider or OpenID Connect Provider (OP) {{OpenID.Core}} that issues Identity Assertions for single sign-on and cross-domain authorization grants {{id-jag}} for a set of trusted applications in an organization's application ecosystem. In {{I-D.ietf-oauth-identity-chaining}}, this is the Authorization Server in trust domain A, which is also trusted by the Resource Authorization Server in trust domain B. | ||
| IdP | ||
| : A SAML 2.0 Identity Provider or OpenID Connect Provider (OP) {{OpenID.Core}} that issues Identity Assertions for single sign-on for a set of trusted applications in an organization's application ecosystem. In {{I-D.ietf-oauth-identity-chaining}}, this is the out-of-scope token issuer that issued the token used as the input to the Token Exchange request as described in Section 2.1. |
There was a problem hiding this comment.
In my conceptualization of things, that second sentence, "In {{I-D.ietf-oauth-identity-chaining}}, this is the out-of-scope token issuer that issued the token used as the input to the Token Exchange request as described in Section 2.1." is not a correct framing.
There was a problem hiding this comment.
That was a reference to this section: https://www.ietf.org/archive/id/draft-ietf-oauth-identity-chaining-06.html#section-2.1
In this flow, the client is in possession of a token that an authorization server will accept...
The Identity Chaining draft doesn't specify what occurred that caused the input token to be issued.
There was a problem hiding this comment.
Yeah, you are right, of course, that Identity Chaining draft doesn't specify how the input token was issued or who issued it. But much of that draft pretty strongly implies that it's likely an access token issued by the domain A AS. So I guess it's not wrong but the framing/phrasing is, to me, somewhat jarring and unnecessarily confusing.
And I think somewhat jarring and unnecessarily confusing is kinda apt for the whole split envisioned by this PR and the impetus behind it.
bc-pi
left a comment
bc-pi
left a comment
There was a problem hiding this comment.
I do think there's merit in exploring AT and/or RT as additional or replacement option(s) for the input token. But I don't think splitting the IDP is directionally correct for this work.
I think your concern is that the user identity data required to populate the ID-JAG is typically in the IDP's directory. I think that data can be propagated to other places, or in case the directory source is elsewhere, the same can be used in the Enterprise Authorization Server, so I feel having the ID-JAG issuer as being decoupled from the IdP is a valid use case. The authorization data (i.e. what resources the user is permitted to access and with what scopes) is an authorization concern, which could be decoupled from the IdP, although I agree that today it is common for that information to also be with the IdP. |
This is a possible resolution to the suggestion from on the email thread after the presentation at IETF 124.
(The sequence diagram isn't working in the built draft, so a copy is provided below.)
You can preview the compiled version here: https://drafts.oauth.net/oauth-identity-assertion-authz-grant/aaronpk/idp-enterprise-as-split/draft-ietf-oauth-identity-assertion-authz-grant.html