No clear way to disconnect a single connection from provider

[Keith Donald]

You are correct in that a Connection is a link between a local account and a provider account. However, I was not comfortable forcing capture of the providerAccountId at the level of all AbstractServiceProvider implementations, given it's not needed by the ServiceProvider framework to obtain a Service API.

So we've removed that in the meantime while we think through how we want to handle the case where additional provider profile information is needed to support user stories such as provider sign-in, rendering of connected profiles, etc. This discussion on the forum has been quite helpful in that regard.

Keith

[sfussenegger]

Is there any possibility to follow that process of "thinking through" or contribute to it?

I've made pretty good progress with my spring-security integration but got stuck on exactly this question. As soon as this is decided, I could finish the integration and put everything into production.

If this takes too long though, I'd have to find a solution on my own to get something working. So any decisions, hints, promises, etc that would ease my mind while waiting are very well appreciated

[Keith Donald]

Well, I'm exploring, post-connection, using the Service API returned by a ServiceProvider to insert a ConnectedProfile into a repository that could be retrieved later. So this wouldn't be something ServiceProvider implementations would be required to do, rather it would be a separate (and optional) responsibility.

So I could imagine...
Connect to provider XYZ
Post-connect, store a ConnectedProfile record e.g. profileRepo.insert(serviceApi.getProfile());

On provider sign-in, you'd then query the repo to determine if a connected profile exists by the providerAccountId returned from the authentication dance; if so, you'd sign the associated local user in, otherwise you'd require them to sign-up or implicitly create a local account. To handle this more elegantly, I think we need a OAuth1/2ServiceProvider operation that can simply return a Service API instance without saving a connection. Also, I think OAuth1/2Template should add a new operation that can be used to get a general-purpose RestTemplate for accessing protected resources the ServiceProvider implementations could call.

There is also the opportunity to have a normalized interface for a ConnectedProfile that could be implemented across Service APIs.

These are just some things I've been thinking. I need to actually prove this out in code to see how it looks. If you think your spring-social-security module is ready for review/to integrate some of these ideas, I'd be happy to work with you on this.

Keith

[sfussenegger]

sound pretty good to me. please let me know of any (even experimental) code you make available (github branch I guess). I'll give feedback whether it plays nicely with the spring-security integration.

[Keith Donald]

I've created a "connect-m3" branch that contains an initial commit of the refactoring work to address the issues brought up in this thread. This branch is being actively developed, and I hope to have it complete and ready to merge by the end of the week.

Here's the link:
https://github.com/SpringSource/spri...ree/connect-m3

Keith

[sfussenegger]

Sorry I wasn't able to reply earlier since some urgent matters have kept me busy for the last week.

The branch is gone, so this is in master now?

Cheers, Stefan

[Keith Donald]

Yes. Provider Sign-up support is the one thing we still need to add. I'm working on that today.

[Keith Donald]

Stefan,

The latest ProviderSignInController should give you an idea of how Spring Security based OAuth authentication could be done:

https://github.com/SpringSource/spri...ontroller.java