Relationship Based Access Control in IoT and User Managed Access

English on April 25th, 2017 No Comments

Relationship Based Access Control (ReBAC) models originate from access control considerations made for Online Social Networks (OSN). In original ReBAC studies User-to-User (U2U) relations determine the access control decision made whenever a user (accessor) tries to access a resource. Policies typically evaluate the type, depth and strength of the U2U relation between the accessor and the resource owner (see Fong et al, Carminati et al).

Example: The friend of my friend has access to the picture that I posted.

Considering only U2U relations implicitly assume an “owns” relationship between resource and user. Access rights to the resource are determined by the U2U relation between the accessor and the owner. Other use cases in OSNs exist in which U2U relations are not sufficient and User-to-Resource (U2R) relations need to be considered (see Sandhu et al)

Example: The commenter of a blog entry might be allowed to contact another commenter of the same blog entry.

These expanded ReBAC models require U2U relationships (e.g. friend, parent, child) and U2R relationships (e.g. like, commented, tag). The relation “user commented on a blog entry” constitutes a U2R relation between the commenter and the blog post. The relation between two commenters of the same blog entry is a 2-hop U2R relationship.

Deriving access control decisions require policies (e.g. only direct friends are allowed to comment on my posting). In the context of OSNs it is assumed that many resource objects (pictures, postings) exist and have similar access policies. There are only few relation types (typically friend) and/or user groups (e.g. circles, friend lists). With that in mind a few policies are sufficient to represent access controls to many objects.

In case of the Internet of Things (IoT) access control need to be more granular. There is a need to have many more relation types between identities (U2U) and policies which govern the access to resources. A model as used for OSN would be very complex and policies would be very difficult to overlook and manage. Typically, this approach would lead to a vast growth of relation types and policies. Something similar to what we already know as role explosion from RBAC.

The aspects described above led us to another way of looking at ReBAC. We started to model the permissions directly as relations (edges) into the graph and reduced the number of policies to a single policy which basically says that an identity is allowed to access a resource if a path of a specific type between the identity and the resource exists.

Example: The delegate of a user with access permission to a third party resource has access to that resource as well

View from Ron' perspective. Seeing the permission path from Delgado to Ron's UserProfileData

View from Ron’ perspective. Seeing the permission path from Delgado to Ron’s UserProfileData

The policy evaluation function is:

F(A, R, P) = {0, 1}

with A = Accessing Identity, R = Resource, P = minimum permission type, {0,1} = the deny or permit decision

Under this model permissions are described as U2R relations and can then easily evaluated using Graph traversal algorithms.

To take the model even further we introduced access requests as U2R relations to represent User Managed Access (UMA) scenarios. The relation “read access requested” is converted to a “read access allowed” relation as soon as the resource owner approves the request.

Register with SSOCircle and get a real impression on ReBAC and MyIdentityGraph.

Tags: , ,

Next Generation Identity and Access Management

English on April 6th, 2017 No Comments

SSOCircle recently introduces a Graph based identity management system with user manageable access permissions and an entitlement API.
MyIdentityGraph

Enter ReBAC (Relationship Based Access Control. Add ReBAC to ABAC (Attribute Based Access Control) and RBAC (Role Based Access Control) and get StarBAC.

ReBAC can be described by the explicit tracking of relationships between identities themselves and identities and resources plus the expression of access control policies in terms of these relationships. A good fit for the next generation IAM challenges of the CIAM and IoT age and complex non hierarchical relationships.

View from Ron' perspective. Seeing the permission path from Delgado to Ron's UserProfileData

View from Ron’ perspective. Seeing the permission path from Delgado to Ron’s UserProfileData

Enter standardized Authorization as a Service. XACML… ,yes, but JSON and REST based. Protected with a OAuth bearer token.

Find your path … Welcome MyIdentityGraph!

Read more at www.ssocircle.com

Tags: , , , , , , , , ,

Configuration and Metadata Certificate Changes

English on August 7th, 2016 No Comments

Applies to the Public IDP. Not to our IDPee offerings.

Update: Public IDP Metadata will be replaced during a maintenance window at the weekend of 13/14th August 2016. We do not expect downtime but there may be some changes needed at your service provider.
SSOCircle Root CA certificate used for client certificate authentication will also be replaced in the first week of August.

Details on the changes:

  1. Replacement of the SSOCircle Root CA Certificate
  2. SSOCircle Public IDP Certificate and its SAML Metadata will be replaced. The certificate will be signed by the old SSOCircle CA certificate. The SAML Metadata and the endpoints itself are considered deprecated.
  3. New Public IDP Metadata will be introduced with new endpoints, new keys and certificates signed by the new SSOCircle CA. The new Public IDP Metadata should be used with new deployments and should replace the old metadata.
  4. Client certificates used for strong authentication when signing in to the IDP will now be signed by the new SSOCircle Root CA certificate. Old certificates will continue to work

What you need to change:

Details depend on your SP implementation and configuration. The following points should only direct you into the right direction.

Deprecated use of old IDP Metadata (may be removed in future)
During the weekend of 13/14th August replace the SSOCircle IDP certificate in your SP configuration with the new certificate or just replace the metadata (if your SP supports SAML Metadata)
Deprecated SSOCircle Public IDP Metadata

Recommended: Use of new IDP Metadata
From now on, you can use the new IDP Metadata (If your SP supports SAML Metadata)
SSOCircle Public IDP Metadata

If you need to change your SP configuration manually, you need to change the certificate and properties as listed in IDP Configuration Changes.

SSOCircle Root CA Certificates can be found at the URL:

SSOCircle CA Certificate
SSOCircle CA Certificate (deprecated – legacy use only)

Tags: , , , ,

Enable Key Generation in Chrome

English on June 6th, 2016 No Comments

The following article refers to the process of generating client certificates at the SSOCircle Public IDP. In the PKI functionality of SSOCircle IDP we allow the automatic generation of keys and the enrollment of X.509 certificates. Client certificates are used for strong authentication. These certificates are not related to the certificates used with SAML single sign on.

As of Chrome 49 the keygen tag is deprecated and automatic generation of keys as used in the public IDP is turned off by by default. In order to use the automatic enrollment with Chrome enable it by executing the following steps:

  1. Open “Settings” from the beacon icon
  2. Click on Privacy: “Content Settings”
  3. keygen2

  4. At Key generation: Check the radio box “Allow all sites to use key generation in forms” or as a alternative: “Manage Exceptions” an enter idp.ssocircle.com as allowed hostname pattern
  5. keygen

Tags: , , , ,

Impressions from European Identity & Cloud Conference 2016

English on May 19th, 2016 No Comments

This year the European Identity and Cloud Conference celebrated its 10th anniversary and it is impressing how the event and the company KuppingerCole itself evolved. The conference turned to one of the leading events in the IAM industry with over 700 participants and KuppingerCole is now a global player with operations and partnerships in the US and APAC. During the last 10 years the industry and the vendor landscape changed noticeable: Comparing the platinum sponsor list of EIC 2007 and 2016 you will only find Microsoft on both.

EIC_2016_Logo_red_grey When travelling to EIC, I always ask myself: What will be the hot topics this year? What will be announced dead? Unlike in former years the answer to the first question could easily be guessed beforehand: Blockchain. Yes, undoubtedly Blockchain was the hot topic – speakers only varied by using “Distributed Ledger” when they tried to avoid the word “Blockchain”. A full day pre-conference workshop on Monday and a full day breakout track centered on Blockchain technology and their use cases. But it also became clear that the technology is in early stage and the usages and benefits are not yet obvious. Andy Land tweeted: “Feels like a technology is looking for a problem”. According to Sebastien Meunier the technology is currently and the next 8-18 months in experimentation phase, standards will be available in 2-3 years and in 4+ years we will see mainstream adoption.

Newcomers to the conference might be impressed by the fully packed agenda which provided sessions from 8:30am to about 8 pm. Attendees who visited EIC 2008 might remember that the KuppingerCole team had been even more relentless introducing concepts like birds-of-a-feather sessions at 7:00 in the morning. This year the team provided an upgraded conference app with a polling feature and the opportunity to ask questions which were displayed and answered by the speaker at the end of the talk – a very well received improvement of getting feedback from the audience.

The main conference started at Tuesday afternoon with the keynote of Martin Kuppinger, followed by other high quality keynotes, continuing on Wednesday and Thursday with a mixture of keynotes and breakout sessions and a final workshop day on Friday.

In the opening keynote Martin Kuppinger described the new role of the CIO and CISO. As the IT moves to the cloud and utility computing becomes reality, IT knowledge is not so important anymore. IT moves closer to the business. A CIO has to decide whether he follows the path of a Chief Infrastructure Officer or the role of a Chief Innovation Officer (aka CDBO=Chief Digital Business Officer). According to Kuppinger the CISO will be part of the Corporate Audit / Enterprise Risk Management department and will be responsible for the governance (security, privacy, data protection) of all areas (Business IT, Operational IT, IoT).
Kuppinger listed the 15 Top Innovations for Business Agility

  1. Cloud IAM
  2. Big Data & Cognitive
  3. Industry 4.0 & Smart Manufacturing
  4. IoT
  5. Identity Relationship management
  6. Consumer IAM
  7. User behavior analytics (risk mitigation)
  8. Real Time Security Intelligence
  9. Machine Learning & Depp Learning
  10. Microservices
  11. Device Mesh
  12. Privacy & Agility by Design
  13. Ambient user experience
  14. Robotics
  15. Distributed Ledger & Blockchain

and the top 5 from a disruption perspective:

  1. Distributed Ledger & Blockchain
  2. IoT
  3. Consumer IAM & Identity Relationship Management
  4. Big Date & Cognitive
  5. Privacy & Agility by Design

Mia Harbitz, advisor to the World Bank, illuminated totally different aspects of identity and gave the audience new food for thought. To quote her definition of Identity Management:

A combination of systems, rules, and procedures that are defined between an individual and organizations regarding the entitlement, use, and protection of personal information in order to authenticate individual identities and provide authorization and privileges within or across systems and enterprise” boundaries.

Identity is required to have a prosperous life. It has dramatic life implications considering the fact that estimated 1.5 billion persons are unable to prove their identity because they have no birth registration and without that they have no access to many services – for example a child with a birth certificate receive 3 times as much vaccines. Another aspect discussed is the need for identification of individuals among the 60 million refugees to provide them access to services. A difficult endeavor due to capacity, expertise and agility restrictions of national governments and the lack of trust to national systems of failing countries. Could this be a use case for a Distributed Ledger/Blockchain?
A panel session further discussed these topics and raised some interesting aspects: Whereas in first world countries over-identification is the problem (privacy concerns), in most countries it is under-identification. Harbitz mentioned a report from “Le Monde” which states that 20% of the passports created in France are based on wrong identities. It is difficult to bootstrap identities and there is no concept of “accuracy of authentication” in many countries.

Ian Glazer described the identity industry as having its TCP/IP moment – similar to the transition from diverse network protocols and the time one had to pay for the TCP/IP implementations to the point where the TCP/IP stack became free and a default and natural ingredient of systems. Identity is currently not widely acknowledged as the key to customer satisfaction and business growth. The identity industry needs to formally professionalize and have organizations where idm practitioners can turn to for advice – similar to ISACA, IAPP or (ISC)2. He announced that Kantara offers a place to support this idea: https://kantarainitiative.org/digital_identity_professional/

Andre Durand’s keynote about disruption “it can kill you … or make you reach” described many examples of changes in the industry and the collateral conflict as humans resists to change resulting in a “happy struggle”.

“In near future we will tell our grandchildren: Believe it or not, I used to drive my car by myself …”

Eve Maler lectured about the risks and rewards related to the Connected Consumer. Giving consent to data sharing is still not solved adequately. Consent standards will help here: OAuth2, OpenID Connect, UMA, Profiles for health data (FHIR API), Consent & Information Sharing Kantara Work Group, commonaccord.

This year’s European Identiy Award winners:
Best Innovation / New Standard: STIX, TAXII & CybOX
Acronym helper:

  • STIX=Structured Threat Information Expression
  • TAXII=Trusted Automated Exchange of Indicator Information
  • CybOX=Cyber Observable Expression

The initiatives originated from the US Department of Homeland Security and are now transitioned to OASIS Cyber Threat Intelligence TC in order to define a set of information representations and protocols to mode, analyze and share the data.

Best Innovation in eGovernment / eCitizen: GOV.UK Verify – UK Government Digital Services (GDS)
GOV.UK Verify is an identity vetting service for British citizens. After initial verification of your identification through a certified company (like Verizon or Royal Mail), a person can use British Govenrment Services (e.g. HMRC tax services) very easily.

In a track session Adam Cooper demonstrated the huge savings the service can provide by the “Blue Badge” service use case at a UK county which is soon going in private beta.
Resource: Open Identity Exchange

It is not about identity. it is about building ecosystems of trust

Best Consumer Identity Project: TomTom IAM
TomTom introduced a new standard based IAM platform on the ForgeRock stack to manage identities of customers and devices for services like MyDrive or MySports.

Best Approach to Improving Governance and Mitigating Risks: Qvarn Platform
Qvarn is a platform which was developed for the construction industry federations of Sweden, Finland and the Baltics to securely provision and manage the identities of construction workers with strong privacy requirements (privacy by design). The platform is free open source based on Gluu IAM

Best IAM Project: dm-drogerie Markt
dm-drogerie Markt received the award the second year in a row. This year for the deployment of RFID tokens to provide workstation access and SSO with full traceability.

Best Cloud Security Award: Orange Business Services
Provides their customers seamless access to cloud based applications with multi-factor authentication.

Special Award for Responsive Innovation: Taqanu Bank
This category was awarded for the first time. Taqanu Bank is a new bank leveraging blockchain technology to provide limited debit banking cards to people without a residence or cannot prove their identity (e.g. refugees) who otherwise would not have access to a traditional KYC banking account.

Special Award for Best Project in Research: Leeds Beckett University, Institute for Information Industry, Taiwan, R.O.C. Taiwan
Implementation of a Cloud Computing Adoption Framework (CCAF) with multi-layered security based on the integration of firewalls, identity management and encryption.

Side notes:
Real time security intelligence was declared to be the next-big-thing in 2014 by Martin Kuppinger. In 2016 you really found it to be very present on the agenda.
Dave Kearns was missed this year as a moderator. Hope he is fine.

Inspired by the event it is time to thank the KuppingerCole team for organizing the European Identity Conference for the 10th time. The team is really doing an excellent job building and maintaining the identity community. Every year the event organization seems to be even more perfect than the year before. So, mark the date for EIC 2017 on 09.-12. May 2017 at the Dolce Munich.

Tags: , ,

Microsoft Office365 SAML Vulnerability: Authentication Bypass

English on April 30th, 2016 No Comments

The vulnerability in the Microsoft Office 365 SAML implementation, published last week, dramatically underlines how important it is to handle account federations with due diligence. In the light that such a drastic authentication bypass can happen, not only at a small SaaS and cloud player, but at a provider of the size and importance of Microsoft, everyone should be aware that testing of SSO implementations should not be neglected and it should be an ongoing process.

We do not want to fully recap the vulnerability as there are detailed descriptions published by the researches Kakavas [1] and Bratec [2] who discovered the flaw. In this post we just want to quickly outline the flaw and describe how the vulnerability could be tested with a simple test procedure leveraging our SSOCheck services.

Quick outline and exploit of the Microsoft Office365 Authentication Bypass Vulnerability:

During a SAML single sign on flow the service provider receives a SAML assertion which contains the username (UPN). Office365 examined the SAML message and correctly checked that the assertion was signed by a trusted issuer proofing authenticity and that the assertion was not modified.
You should pay special attention to the phrasing “correctly signed by “a” trusted issuer”. Office365 did not check whether the username actually belonged to the organization of the assertion issuing IDP. In other words, they did not verify whether the IDP was entitled to vouch for the user.

That said the exploit was as follows: If you could control either a SAML IDP which was configured for SAML SSO with Office365 (basically any customer) or the user attributes, you could basically send an assertion with an arbitrary username of any other customer

Guide to test the Office365 SAML vulnerability with SSOCheck:

  1. Set-up an Office365 instance (say: mycompany.com) for SAML SSO and integrate it with the SSOCircle SAML Identity Provider (or our hosted IDP service)
  2. Enable the SSOCheck API for your user or hosted IDP
  3. Configure the SAML test #15 as depicted in the image below
  4. office365-vuln-test

  5. Run the test case

As a result of the flaw, the authentication to Office365 was successful and you were authenticated as user “bill” of the microxxx.com company -having access to emails, files, calendar and user data.

Remember: In that scenario Office365 should have accepted only assertions from the SAML IDP configured for the instance which include usernames of the mycompany.com domain.

It is really not easy to find such a flaw. But isn’t it easy to test against the vulnerability with SSOCheck?

If you are interested in our SAML test services, please check at our web site or drop us a message through the contact form.

References:
[1] Blog of Yiannis Kakavas

[2] Blog of Klemen Bratec

Tags: , , , , ,

Test your SAML Service Provider from the Command Line

English on March 14th, 2016 No Comments

cURL and wget – these tools tend to be of great value when a developer starts programming against a new API. With OAuth, you need to get an access token from one API and query another API for the actual data. Seeing the requests at the command line helps understanding the protocols and errors that might occur.

With SAML things are more complex. The most frequent usage scenarios in SAML assume the use of a browser. SAML messages are often sent through HTTP-POST, mainly because the content can become lengthy. Technically the POSTing of the SAML message to another server is done via auto-posting of a HTML form. Running a SAML SSO flow from the command line imposes challenges, which go beyond the simple use of cURL or wget.

When we first launched our SAML Testing API “SSOCheck”, we also provided a tool, implemented as a Firefox extension, to make running SAML flows leveraging the test API easier. Despite that we constantly receive requests to provide cURL samples which can be used to run tests. Thanks to our user’s suggestions, we have no prepared a tutorial about how to run SAML Tests with cURL from the command line. It is composed of two parts. The first part will create a script to run a SAML browser profile SSO flow. And the second part builds upon the script from part one and adds testing functionality using the SAML test API. Please start reading the tutorial.

doctor_testing_reflexes_anim_small

[Update: 20/03/2016: Tutorial part II published]

Tags: , , , ,

New Premium Feature: Debugging IDP Integration

English on February 29th, 2016 No Comments

SAML Integration is easy? If you start to get your hands dirty and undertake the first steps in implementing the standard, you will most likely get an error when running your initial tests.

error-sso-medium

You simply might have missed to import your service provider metadata into the SSOCircle of Trust or have something wrong with the different encodings that the standard mandates. Although we provide error messages, many users missed more detailed trouble shooting help. Enabling debug information is a feature which was requested very often. We are happy to announce that it is no available. Read more at the knowledge base.

Tags: , , ,

Banks ignore crypto checks in credit card transactions. Standards are not enough!

English on January 23rd, 2016 No Comments

The newspapers “Zeit” and “c’t” revealed that credit cards with new chip-and-pin based security (EMV) can be cloned and used for payments.

At first glance very surprising as EMV credit cards are smartcards with crypto graphic measures, which allow a bank to recognize modifications to cards or transaction data. These cards are per se more secure than older cards which only rely on data stored in an easily copied magnetic stripe.

thief_stealing_credit_card_1600_clr_7276
So what happened? The answer is simple: Although the EMV standard is well designed and secure, some banks did not implement the cryptographic checks. As a result, the system falls back to the less secure standard and approves the payment transaction.

What do we learn from that story? It is not enough to trust in blind faith, if someone says they rely on secure standards. Whether it is a credit card or a single sign on network, you better CHECK it. At least if you can! For SAML service providers SSOCircle provides you with SSOCheck to verify the crypto security of your “trusted” SaaS provider. More about SSOCheck is here

If you are interested to read more about the MacGyver credit card fraud, here are the links to the original articles in German:
Zeit Article
c’t Article

Tags: , , ,

Session Timeout – another useless Security Brainchild?

English on January 7th, 2016 No Comments

A synonym for “timeout” is “break” or “pause”. Sounds like a good thing – in principle. When it comes to “session timeout” perception might be different. What exactly do we mean with “session timeout”? At OWASP you might find explanations similar to:

Session timeout defines an action window which represents the time span in which an attacker can try to steal and use an existing user session.

For the end user timeouts are just annoying and ideally shouldn’t exist or at least should be “infinite”. Finding a balance between security and usability is a challenge that we already know from authentication by passwords: Password protected applications shouldn’t exist either or the password should be at least simple and easy to remember. That translates to: Short, the same everywhere and intuitive like “password”, “aaaaa” or the name of my dog.
coach_time_out
Back to OWASP and their definition about the action window for stealing identities. Session expiration is mandatory unless you want to give an attacker unlimited time to guess or brute-force a valid session token. You definitively need to acknowledge that a session token, for example a cookie, represents your credentials for accessing protected content. During the time of its validity the token is as confidential and worth protecting as username and password itself. This becomes particularly critical if the transport of tokens is in clear, only secured by weak encryption, in shared environments or if you take into account that session tokens can potentially be logged by servers or proxy servers.

Sounds unrealistic? Think of the situation when you go for a meeting and leave you laptop unlocked. Someone can easily access your browser, retrieve cookie information, and go back to his own computer impersonating you. In that case the best prevention would be locking the screen or manually logging out before leaving. But, in the rare case we forgot to lock the screen, an idle timeout would mitigate the risk of cookie theft. If the attacker steals the cookie, say 20 min after you left your desk, an idle timeout of 15 min would have saved you and your data.

If you argue that you don’t need an idle timeout since you can deal with that by reasonable diligence: Remember the Odd Job Trojan in 2011. OddJob infected Firefox and Internet Explorer stealing session identifiers of online banking applications, intercepting manual logout commands from the user, hijacking sessions and keeping them alive by sending periodic requests to the server. Ending up with access to banking account information and transactions for a long time.

Consider weak encryption: The Freak Attack (https://freakattack.com) published on March 3, 2015 allows attackers to intercept HTTPS connections and force the use of export-grade cryptography leaving most Windows, Android, Apple devices and Macs with OS-X vulnerable. And what is the impact to session timeouts? Forcing the use of export-grade crypto means a downgrade in key length to a 512-bit. Nadia Heininger (University of Pennsylvania) was able to factor 512-bit RSA keys in 7.5h on a cluster of EC2 servers for a cost of $104. If your session lasts longer than 7.5h not only the traffic could be decrypted but also your session cookie could be read and USED. An absolute timeout shorter than 7.5h would mitigate the risk to be “freak attacked “.

Coming back to the point: Session expiration should be used to make your systems more secure. More secure, in the context here, means giving the attacker less time to break your safeguards. Please note: Invalidating sessions after timeout or logouts must be done on the client and server side. The latter is the most relevant and mandatory from a security perspective. Removing the session identifier (e.g. cookie) only on the client side is not considered safe.

The safeguards related to session validity are:

Manual session expiration: Provide an easily accessible logout button, so that the user has the ability to logout and end the session whenever his work is finished or paused. Unfortunately nowadays in many social applications the logout button is hidden somewhere to keep the users logged in.
Idle Timeout: Most applications implement idle timeouts which terminate a session after a certain amount of inactivity. The length of an idle timeout heavily depend on the kind of application. According to OWASP common idle timeouts for high-value applications are 2-5 minutes, medium critical applications 15-30 minutes and low risk applications approx. 3 hours.
Absolute Timeout: A timeout after which a session is closed no matter there is user activity or not. The absolute timeout limits the time a hijacked session can be used. Banking and shopping applications typically implement an absolute timeout of 30 – 60 minutes. The absolute timeout heavily depends on application use cases. For some applications a timeout of 8 – 24h does make sense.
Renewal Timeout: Some applications define renewal timeouts, which probably are the most difficult from implementation view point. After the renewal timeout a session identifier is exchanged to a new one, leaving the session itself valid. Technically the renewing of session identifiers limits the time a hijacked session could be used by an attacker without impacting the usability of the normal user as the session remains still valid. But with that approach problems can occur, if the client is still using the old session id when it is already set to invalid. The change of session id can also imply race conditions in which the attacker, not the legitimate user, is able to obtain the new session id.

Some words about session synchronization: In loosely coupled single sign on systems (via SAML, OpenID Connect …) there is no single overarching session. Individual applications create their own local session without revalidating the session on subsequent requests. This constitutes an important difference in behavior from classical web access management systems, which typically maintain a central session and applications verify session validity periodically.

Session expirations, manually or through timeouts, pose challenges to these SSO environments. A manual logout from one system should be propagated to other systems (although there might be good reasons for not doing that). If there is no global logout, the user experience might be a little confusing, since logging off a system might not show the expected effect as you are transparently signed in again through the existing identity provider session – at least if everything is working fine and the session at the identity server is still valid.

And what about timeouts? Does it make sense to propagate idle timeouts? Being idle in one application doesn’t mean you are idle in another application as well. What about idle timeouts at the IDP? Consider the case in which you are surfing one application and then you access another application. If the IDP expired your local session because of inactivity at the IDP, single sign on will not work and users have to reenter their credentials. Is that what you expect from a working SSO system?

SSO integrations are normally more difficult than expected. Session synchronizations are even worse and often do not work in real life deployments. SAML 2.0 specification describes several profiles for single logout. OpenID Connect session management specification is still in draft http://openid.net/specs/openid-connect-session-1_0.html (as of 03/2015). There are some people in the identity community advocating to abandon single logout. Their argument: It is better to know there is no single logout and deal with it (for example by closing the browser window) than relying on a working single logout which in reality might be incomplete or even nonexistent.

Final remark: There is no such thing like a “gold standard” for timeouts. As often in security topics, it is all about risk management. Risk based considerations may help to find a good balance between user experience and security.

Tags: , , , ,