MitreID connect - SSO implementation questions

[ashernave]

Hi there,

I have a question regarding mitreid connect client implementation and I wasn’t sure where should I post it. Feel free to direct me to the right place. I am implementing a resource server, rest-api-server, that I want to work with open id connect with its clients. The full scenario is that I have:

1. a web application (A) which is an openid connect client - implemented based on your sample-web-app.
2. Web application B, an existing restful web server that I want to secure and get identity data to it using opened connect
3. An openid connect server (openAM implementation by Aol) I need web application A to do a restful call to web application B.I already modified the sample to add the rest call to B.

All services are spring-java based and it looks like your solution might fit them perfectly.

My questions are:

1. I understand that I need to send the Access Token in the A to B rest request. Is this true or should I use ID token or authorization code instead?
2. What should be the configuration of B application in this case? it looks like OIDCAuthenticationFilter does authentication only on URL with a specific suffix (“/openid_connect_login” by default)
3. Should there be another way to do authentication in the B application using the access token?
4. Do you have a sample for this scenario. It looks to me like the typical SSO scenario and yet I can’t find resources about it.

I’ll appreciate your answers. Thanks,

Asher Nave

[jricher]

The mailing list (mitreid-connect@mit.edu) is probably a better place for this kind of question, but I'll answer your questions here:

1) You use the access token. You should never send the ID token outside of your application -- it's intended to be consumed by your application directly. If you were to send the ID token to B, B should reject it anyway because (a) the token didn't come from the AS and (b) the token was audience restricted to A.

2) Your application "B" is an OAuth protected resource. This actually has nothing to do with OpenID Connect, since the user will not be present on the call from A to B -- it's A acting on behalf of the user at B. B just needs to know which user is acting, so that's where something like Token Introspection will help, since that will give B a means of calling the AS to find out what the token is good for. I don't know if your server (OpenAM) supports introspection or has another way to get authorization data to a distributed resource server.

3) You're not actually authenticating the user at B, you're getting authorization information related to the token, which includes information of who authorized the token. It's important to realize, though, that the user isn't necessarily still there (authenticated) when A makes the call to B.

4) It's not really SSO as you're describing it but rather simple OAuth, with the difference being that OpenID Connect is being used to authenticate the user to the client application in addition to OAuth authorizing access to multiple resources (like B) in addition to the identity information. This is all pretty straightforward and relatively common OAuth, but approaching it as an SSO problem might have been leading you in the wrong direction.