Single Sign On

[ayoksus]

Hi,

I've worked on a SSO application. The concept is simple.

[*]First, a member login to the site, and after login he/she will open a page with buttons of different sites.

[*]If he/she click on one of the buttons, then he/she will be automatically logged in to the site he/she clicked.

[*]There are form and hidden fields in each button which contain those username, password, etc

[*]The visitor can add a site by fill in the username, password, form action link, and extra fields

[*]For security I just encrypt the values in the hidden fields

 

That's it. However, I came across to a term SAML, and some other terms which are relatively new for me, like Service Provider, identity provider, etc.

So my question is, do I need to apply these terms on my app?

I don't really understand the SAML concept, even I've read about it. I know it's about security, but is my way not secure?

I've tried a framework like simpleSAMLphp, but I really don't know how to implement it on my app. Would anyone share here about your experience with SSO?

 

Thanks,

ayok

[Adam]

SAML isn't a "term", it's an XML-based protocol. The point of it is to provide a standard way of exchanging authentication details via XML. Given it is XML though, I'm not really keen, especially if SOAP was wrapped around it. SimpleSAMLphp is an implementation of it, but after a quick look at some of the examples it looks too tightly coupled with the XML.

 

The "identity provider" is generally a central server, communicated with through some kind of web service that controls user access. "Consumers" or "service providers", are different websites that connect to the identity provider and request access to their service for an end-user, based on the credentials included. The identity provider not only managers the users, but the consumers too.

 

I wouldn't really call what you described as SSO, it sounds like you're just redirecting a user to another website with some POST data. Also is sounds like they have to manually update their details.. So I'm kind of wondering what the point of it is? Do you own/run the other sites you're logging users into? If not I don't think the other websites would appreciate you doing that.

[ayoksus]

I wouldn't really call what you described as SSO, it sounds like you're just redirecting a user to another website with some POST data. Also is sounds like they have to manually update their details.. So I'm kind of wondering what the point of it is?

 

Hi. Thanks for your explanation.

The point is, the login owners don't need to go to the sites to login. They just go to my site and click on the button from the panel, and then they're logged in to the site. They don't need to update their details, they just need to add their details if they have more login site.

[Adam]

By having to manually update their details, I meant they first have to input them into your service to login to somewhere else. Then if they ever changed their password for example, they would need to update it within your service too. Right? If so, that's not what SSO is, and not what SAML was built for. Which would explain your confusion..

 

SSO is meant to be a central, true single login for multiple sites. No duplicate data, it's just all one database of users that multiple websites use, through a service-based interface. Obviously a consumer (a website) can then store more more information specific to the user if they like, but the core of the data is all managed by the "identity provider".

[ayoksus]

Hmm.. I see.. Thank you, I now understand why people use SAML.

 

So with SSO, people should just be able to login without sending their login variables at all? What kind of data's possibly in the XML so that people can login without sending their username and password? I've seen the XML, but I don't really understand what's going on there. If we send anything other than the username/password, does it mean that the Service Provider (our partner) has to modify something on their login system as well?

 

It seems like you're not so exited with SAML or simpleSAMLphp. What are my other options to create a real SSO? I received a .cert and .pem from a company that would like to have a partnership with us. They're suggesting SAML as well.

 

Thanks again for sharing your knowledge with me.

 

Regards,

ayok

[Adam]

No the credentials are still sent in the request when the user logs in. The difference being that it's the identity provider that performs the authentication, and then returns a success/failure response to the consumer. So yeah, all consumers or "service providers" if you prefer, must use identity to perform the login. If your partner already has an established login system, that could be a fair chunk of work on both ends.

 

I'm not saying SSO is the be all and end all by the way, just explaining what SSO is exactly. I've not researched SAML or simpleSAMLphp enough to give an accurate answer on whether you should use them. I was just going on first impression, although I'm not a fan of such bloated XML-based services so I could be biased.

[ayoksus]

Hey.. thanks man. you've enlightened me. I understand the concept now. You are a guru. 

I'm going to search further.