Get OpenID Connect id_token by the authentication request with prompt=none and verifying the sub to be the same with what you expected seem to suffice your needs. Am I missing something? On Wed, Apr 20, 2016 at 05:05 Fregly, Andrew <afre...@verisign.com> wrote:
> Thanks for your response John. I also got a good response from Brian > Campbell and appreciate that. I will respond separately to Brian’s response > as I think it would keep things clearer to do that. > > The problem we have for using OpenID Connect is that it combines the role > of Authentication Service with the role of Authorization Service. Perhaps > the following description of what we want to do will clarify why this won’t > work for us: > > The basic problem statement is that we need to have a client application > authorized by a Service Provider based on proof that a user is currently a > member of some organization. This assumes the organization has previously > established some level of authorized access with the Service Provider. > > Here is an example: Suppose I am a member of SomeOrg Inc. Suppose SomeOrg > Inc. is doing research that requires it to gather data over the Internet > from a number of data providers. The data providers require authentication > and proof of organizational membership in order to authorize various levels > of access to their data. The data providers do not consider having an > account with them or a Public Identity Provider to be suitable for proving > that I am still a member of SomeOrg at time of authentication. They would > have no way of knowing whether or not my relationship with SomeOrg still > exists at that time. The data providers would therefore like the Client > software to authenticate me against SomeOrgs Identity Provider. This would > be good proof that I am still a member of SomeOrg at the time I > authenticate. This authentication would enable the data providers > Authorization Server to grant me access appropriate to a member of > SomeOrg. Note that as a prerequisite to all of this, SomeOrg will have > used an out-of-band process to set up a trust relationship for SomeOrg's > Identity Provider with the data provider’s Authorization Service, and will > have negotiated authorization claims to be granted to SomeOrgs members. > > What I am having difficulty with is in knitting together an approach based > on the he OpenID Connect specifications, SAML specifications, and OAuth > RFCs and drafts in a way that supports the above use case end-to-end. The > OAuth RFCs and drafts almost get me there. What seems to be missing is a > way of telling an Identity Provider the URL for the Authorization Service > (the required Audience claim in an authentication assertion as defined in > RFCs 7251, 7252 and 7253), and then a requirement that the Identity > Providers put the supplied Audience Identifier into Authentication Tokens. > Perhaps a little further back-and-forth with Brian will resolve this. > > I can go into deeper detail if needed. If this is off-topic for the OAuth > working group, let me know. > > Thanks, > Andrew Fregly > Verisign Inc. > > > From: John Bradley <ve7...@ve7jtb.com> > Date: Tuesday, April 19, 2016 at 2:06 PM > To: Andrew Fregly <afre...@verisign.com> > Cc: "oauth@ietf.org" <oauth@ietf.org> > Subject: Re: [OAUTH-WG] Building on the protocol in the draft “OAuth 2.0 > Token Exchange: An STS for the REST of Us” to include Authentication Tokens > > Looking at OpenID Connect and it’s trust model for producing id_tokens > that assert identity may help you. > http://openid.net/wg/connect/ > > Unfortunately I can’t quite make out what you are trying to do. > > It sort of sounds like you want an id_token from a idP and then have the > client exchange that assertion for another token? > > John B. > > On Apr 19, 2016, at 1:18 PM, Fregly, Andrew <afre...@verisign.com> wrote: > > I have a use case where a client application needs to authenticate with a > dynamically determined Identity Provider that is separate from the > Authorization Service that will be used issue an access token to the > client. The use case also requires that as part of authorization, the > client provides to the Authorization Service an authentication token signed > by an Identity Provider that the Authorization Service has a trust > relationship with. The trust relationship is verifiable based on the > Authorization Service having recorded the public keys or certificates of > trusted Identity Providers in a trust store, this allowing the > Authorization Service to verify an Identity Provider’s signature on an > authentication token. > > In looking at the various OAuth RFCs, particularly RFCs 7521, 7522, and > 7523, I see that they get me close in terms of supporting the use case. > What is missing is a means for solving the following problem. These RFCs > require that the Identity Provider put an Audience claim in the > authentication token. The problem with this is that I do not see in the > RFCs how the Identity Provider can be told who the Audience is to put into > the authentication token. This leads me to the title of this message. The > draft “OAuth 2.0 Token Exchange: An STS for the REST of Us” defines a > mechanism for identifying the Audience for an STS to put into a token it > generates. That would solve my problem except that the draft limits the > type of STS to being Authorization Servers. What is needed is this same > capability for interacting with an Identity Provider. This would enable > RFCs 7521, 7522 and 7523 to be useful in situation where the Identity > Provider needs to be told the identity of the Authorization Service. > > I am new to interacting with the IETF. I also am not an expert on the RFCs > or prior history of the OAuth group relative to this topic, so please point > me to any existing solution if this is a solved problem. Otherwise, I would > like to get feedback on my suggestion. > > Thanks You, > > Andrew Fregly > Verisign Inc. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
