Network Login

[nilshoerrmann]

Symphony Factory will bundle a unified Symphony Network toolbar. While we can design the look and feel of this area, a few quite important things need to be prepared on the Symphony website:

• We need a global Symphony login.
• We need an XML feed providing the data shown in the network drawer.

In a chat with @allen we came up with the idea of creating an extension that offers all needed things:

• a dynamic Data Source that fetches the XML,
• an XSL template to automatically build the toolbar and
• the Symphony login.

I have no idea if anything has been prepared for the login yet, I just suppose it's not an easy task. It needs to be secure, has to work cross-domain. It would be nice, if we could – as we do on the current main site – display the number of network visitors. Although I'm not sure if that might complicate things too much.

The question is: who is taking care of this?

The XML feed can be static for now and we can create a first version while working on the layout. What about the login? How do we deal with sites currently using Github as authentication service?

I just want to make sure that we take care of these things now because the release on Factory won't help us much if these other things aren't working.

/cc @allen, @nickdunn, @bauhouse, @alpacaaa and @lewiswharf.

[nickdunn]

I wouldn't even do it as an extension, just have the Dynamic DS return the HTML for the header as served by the "master" Symphony site, then network sites just do a copy-of. The problem arises with the actual signed in stuff itself. Are we trying to achieve multi-domain single sign on? That's really not easy. An alternative:

• if there's a login form in the header, have it post to the "master" site which can then redirect back on success
• to show the logged-in state, the Dynamic DS in its request to the master site can pass a login token/cookie (which might be set with JS on each network site?), so that the master site knows the user is signed in and the HTML returned is correct

Without knowing more about how Allen and Soario intend on building the infrastructure, it's difficult to say.

I'm assuming above that all network sites run from one single sign on. Which is problematic for SymExt because, as you say, it uses Github, and this ideally won't change.

Allen, what's the plan?

[nilshoerrmann]

Are we trying to achieve multi-domain single sign on?

I think that's what Allen said in Cologne.

Which is problematic for SymExt because, as you say, it uses Github, and this ideally won't change.

Allen told me something about linking the Symphony login to the Github profile.

[allen]

The idea was to integrate our membership system with Github oAuth.

Essentially this will allow anyone to register with their existing Github account. Existing members can also optionally link their account with Github.

I am aware that this doesn't solve our sign on issues though and if anything complicates it somewhat since we won't be able to solely rely on Github's oAuth since not everyone Symphony member will have an Github account. The alternative is to make Github account a prerequisite.

I'll need to think more on this.

[nilshoerrmann]

Personally, I don't think Github should be an requirement. If I'm not contributing the the system and just using it to create sites, there is no need why I should be on Github. Commenting and doing other stuff on the network isn't Git related at all.

I don't have enough technical knowledge in this matter, but would it be an idea to provide our own Symphony oAuth service? The main Symphony account could then be linked to other services like Github.

Are we trying to achieve multi-domain single sign on?

An additional note about this: Just thinking of the user experience, it would be strange to have a unified network toolbar but separate accounts. If the logins were separated, it could happen that you switch from one site to the other (which will then look similar and the users won't necessary notice that they are technically switching sites) and on the first site the toolbar will recognise you as a logged in user and on the second one it will ask you to login or create a new account.

[nilshoerrmann]

I'm assigning this issue to @allen because it's something that needs to be handled/provided by the main site.

[allen]

Thinking about this more, it looks like however we do this, we won't be able to get away from creating our own SSO server. Essentially, this server will be used by the main site, along with all approved network sites. We can look at implementing this using the SAML standard. There are a couple of ways to could implement this:

1. Shibboleth: http://shibboleth.net/
2. SimpleSAMLphp: http://simplesamlphp.org/

Luckily, it's a mostly set and forget affair, since they're based on the SAML standard.

I will need to do more research and play with these before I come back with more thoughts on this.

[nilshoerrmann]

Symphony Factory incorporates the user's profile into the network toolbar as an inline area: what should we do for unregistered users? Should we provide a inline registration form or should we link to a page?

Regardlessly, which information does the network store for each user? So far we have:

• username
• name
• email
• location
• website
• bio

We didn't include a timezone selection because Factory includes a relative time function that will convert given absolute dates and times. Is that okay?

[lewiswharf]

Should we provide a inline registration form or should we link to a page?

I've been thinking about this quite a bit lately and I believe that may be determined by the number of fields. Should ninja related info specifically related to availability for work be incorporated into the main profile or a child profile viewed within the ninja site?

My first thought is it would benefit to have this incorporated into the main website because it would make it easier for users to update their availability.

[nilshoerrmann]

One general note about the profile: we currently include the profile editor in the network toolbar, but this is just a proposal. If profiles need to be handled differently, we can just drop that idea.

[allen]

I idea was to have all the info for a member at a single place: http://auth.getsymphony.com

This solves Mark's concern, making it easier for members to edit their profile. By default, authorised network sites will be able to request a member's basic set of profile. This is essentially the fields that exist for the inline profile editor in the network toolbar.

Network sites can also request additional profile information from the "Auth" network site. On a member's full profile page, there will be sidebar tabs that point to additional profile details. For example, there will be sections for "Work", "Contributions", "Github" and possibly others.

The "Work" tab can have profile information that relates to job status, etc. while "Contributions" relates to a member's community role, such as a working group member, or a forum moderator, etc.

These additional tabs can be easily expanded on as more network sites are introduced.

Here are some additional information about the server:

1. The "Auth" network site resides on a dedicated server that can only communicate through a secure socket: HTTPS/TSL.
2. The server only allows a whitelist of approved network sites to gain access.
3. Network sites that resides on the *.getsymphony domain will automatically have access to the shared member session as the main site. External domain sites must make request to the "Auth" server via RESTful API (returns XML) and must handle sessions itself.

[alpacaaa]

Good to know that both subdomains of getsymphony.com and external domains will work!