Update: We have enabled the auto login again. More info on this: Auto Login Enabled For Good
Update: the auto login feature has been disabled this morning, 19th of February at around 11am GMT. More info on this: A Necessary Update On Auto Login
We have released a critical piece to improve the overall login process today which will automatically log you in if you have an already valid authentication cookie or client certificate in place. This means you no longer have to click Login link in the header when you open any page on SCN.
I would like to take this opportunity to give you some background on the architecture and the technical implementation of how registration and authentication works on SCN with some view back in history, but also get into some details on the auto login implementation.
Before New SCN
A couple of years back SCN was using SAP NetWeaver technology and its application server as the foundation for most of its applications forming the SCN platform. Although SCN consisted of multiple applications, from the good old forums, the blogging application, the SCN Wiki and the Portal KM for document and podcast storage, we had single sign on (SSO) in place very early. Back then it was done using the so called MYSAPSSO2 cookie, which would be passed to all participating applications in the *.sdn.sap.com domain. Once you authenticated on SCN, this cookie would contain your login ID in a securely encrypted way, which could then be analysed by any of the SCN applications to automatically login n authenticated member.
Registration for SCN was custom built and specific to our needs as was the management of SCN Terms of Use and Privacy Policy checks. All user information was stored in our central, external LDAP, which over time opened up to also store user profiles of other external SAP web properties. Your user specific information was made available via the SDN Business Card, where every single user was able to edit their profile information and which information to show to all other members.
This approach worked fine for the time when SCN was still an isolated platform, where there was no need to be also connected to other cloud applications and services with a more generic and standard approach to SSO and central user profile management.
SAP ID Service To The Rescue
SSO with the old SCN stack for other external sites has been done a couple of times and always ended up in large implementation efforts to integrate with the SAP specific architecture inherited from SAP NetWeaver AS. For similar reasons, profile syntonisation was only done when absolutely necessary, which resulted in a sub-optimal end user experience.
The work on SAP ID Service (SAP IDS) started roughly three years ago out of the growing demand to have a better integration of all external SAP web properties.
From a service consumer point of view I would describe the high level requirements as the following: - SCN members should be able to login to any SAP website using their credentials - User profile information should be easily accessible - Integration effort should be minimal
SAP IDS implements the SAML 2 standard, which provides all of the above requested functionality. When we started the SCN migration, SAP IDS was still work in progress and SCN became one of the first consumers of this new service. Living on the edge of new development can be fun, but often it is not the most satisfying experience for end users.
We went live in March 2012 technically with SSO via SAML 2 and profile sync implemented. But the actual login process still involved the old SDN Portal login page. The Portal functioned in this case as the login form. Once an SCN member would click the login link, the authentication process would get triggered, and SAP IDS would forward the request for user credential input to the SCN Portal page. Once the user entered his/her credentials, they would get send to SAP IDS where the verification would happen, and when successful would be redirected to New SCN in form of a SAML response.
The old login form was a huge break from a user experience perspective, with switches between different domains, visual breaks and different styles of UI design. There was also the technical dependency to the old Portal platform for a small functional artefact, the login form, but this ended up in a big obstacle during maintenance downtimes of the Portal where only SCN members with an installed browser certificate (SAP employees and some s-users) where able to login. During that time the SAP IDS team was already working on providing a better way to solve the problem. With SCN being an early adopter of SAP IDS, we switched to the login and registration popup which would prevent the domain switch and instead provide a much better and more transparent UI integration. It was a necessary and major switch and I won’t deny that we had problems shortly after enabling it. Some users were not able to login, problems during registration occurred, but SAP IDS was able to deliver solutions to occurring problems in very short time frame.
The SAML Dance
Effective standards often rely on loose coupling and lightweight protocols. SAML 2 relies here on the end user browser to manage the workflow, also known as the SAML Dance. Here is an excerpt from the document SAP Insider Enable Secure Single Sign-On in the Cloud:
How It Works
When a user requests a resource from a service provider — for example, if the user wants to create a travel booking in an on-demand travel system — the web browser redirects the request to SAP’s ID service. As the central component for authentication, SAP’s ID service checks whether it already has an active session for the user. If an active session does exist — that is, if the user has already authenticated with any of SAP’s on-demand applications that connect to SAP’s ID service — the ID service responds with a SAML assertion. The user’s web browser again redirects the request to the target resource at the service provider and includes the SAML assertion in the request. The service provider then grants access and responds with the requested resource. If an active user session does not yet exist, the ID service checks for valid credentials (like an X.509 certificate) or requests authentication via a username and password. If valid credentials are provided, the ID service issues a SAML assertion and a user session is established on the IdP.
This dance is actually quite interesting to watch and everybody can do this for their own authentication session with Firebug for Firefox or the Chrome build in Developer Tools:
All browser communication during authentication is encrypted using SSL, but with a tool like SAML Tracer you are able to see behind the curtain on what kind of information are exchanged.
SCN Auto Login
Now with all workflow being managed by the browser we end up with one problem which finally brings me to the original topic of this blog post. SSO in general only described the ability to login with a single pair of credentials into multiple systems, but it doesn’t naturally take care of getting automatically logged in.
To provide auto login on the web, what you usually do is to provide a long running authentication cookie which tells the application that the user has authenticated before and no further authentication is needed at this point in time. We have that already, but in our case you get that cookie from SAP IDS. Once logged in, your authentication is available for up to three months, if you check the “Remember Me” box.
But that still doesn’t log you into any site using SAP IDS for SSO. Providing a long running authentication cookie from a consuming site may actually end up in a security issue, when you have to disable a IDS users account for whatever reasons to prevent the user from logging in again, but there is still an authentication cookie from a consuming site in place which circumvents this process.
What we’ve enabled today is a different approach to solve the problem. When opening any page on the New SCN, a piece JavaScript code triggers a request to SAP IDS in order to check for an existing authentication session. If you checked the Remember Me box at login, your authentication cookie or any existing valid browser certificate will identify you and IDS will reply with a positive response. This will result in a page refresh shortly after you opened SCN and you will see your name showing in the SCN header. Simple as that.
SSO comes with SLO, which stands for Single Log Out. When you click the logout button on SCN, you will actually logout of all application which use SAP IDS for login and where you had still any running auth session. Please also keep in mind that most of the login workflow relies on browser cookies. In case you run into any issue, your first aid is usually to remove all *.sap.com cookies and try again (watch out for the IDS_PassiveLogonDone cookie).
Yes, I know this isn’t the visually most beautiful user experience…again. The page refresh doesn’t look that great, and it would be much better if we could dynamically refresh the header UI and controls once we detect the authenticated user. But unfortunately we are currently stuck with what the underlying platform provides in that regard. There is no concept like this implemented in the OOTB functionality and even thinking about how to make this work when accessing your activity stream or considering all possible edge cases makes my head explode.
But the work doesn’t stop here. There are still a couple of touch points with the old SDN Business Card left, like for changing your password, your email address and newsletter subscriptions, which currently still require access to the old SDN Business Card.
There is also a known issue where you may get multiple certificate popups when logging into SCN. This is a known issue and a fix is scheduled for early March 2013.
Credit Where Credit’s Due
Being an early adopter isn’t always the most pleasant experience and I know from hanging out in the SCN Support space that some of you suffered from problems with login, registration or profile updates. But I am convinced now that adopting SAP IDS early was the right way to go and I can’t speak well enough about the professional attitude and the high quality of service this team is providing. I know that Social Login is an item very high on their ToDo list. Being able to login or even register using your social media platform of choice can significantly lower the barrier of entry to SCN for new users.
You better keep an eye on this exciting new SAP product, which will soon have its own space here on SCN. It already provides SSO and supporting services for SAP.com, NetWeaver Cloud, Idea Place and many existing and new services to come. For an in depth look at SAP IDS and its usage with NetWeaver Cloud, check out the video The DevTalks Series - Identity Managment.
I’m looking forward to your feedback on the new auto login functionality. In case you experience any issue, please let us know in the SCN Support space.
Oliver
- SAP Managed Tags:
10 Comments
