Hot answers tagged sso
9
The proposed restrictions are harmful. These restrictions are overkill. They are bad for usability. As a result, I think they will harm users' security more than they help.
Usability is where it's at. In my opinion, right now the #1 most important factor affecting password security is usability: the extent to which users use the mechanism in a way that ...
7
Sure it's possible. What you want to do is called Federation. How you set it up really depends on the applications and platforms you run though. There are a variety of protocols out there that can do what you want; e.g. SAML, WS-Federation, OpenAuth (to a degree), etc.
The applications need to be able to support the federation protocols though.
In theory ...
6
Two views:
Corporate:
Whether you have control over all the machines, or at least the central auth server, you're better off with SSO. One place to hire employees, one place to terminate them, one set of credentials they have to worry about. Individual server compromises shouldn't leak credentials. Users are less likely to get annoyed, forget passwords, ...
6
The question is very broad and it is hard to guess what you are actually asking. You can find the specification at http://openid.net/developers/specs/
Kerberos is typically used in a controlled environment. In that environment there are known and trusted Kerberos servers ("key distribution center"). The Kerberos server authenticates the service provider to ...
6
The way that single sign-on has been implemented for the Stack Exchange Network is very interesting. It makes use of HTML 5 Local Storage. Depending on the browser support that you require you maybe able to use a similar method.
You can check out the stackoverflow blog post Global Network Auto Login for more details.
5
The 8 unique characters is a bit on the excessive side.. Just checked and there are fewer than 1500 words in English dictionaries, with 8 or more letters that are all unique, so what you are also doing is not accepting dictionary words. Not that this is a bad idea, but you could say just that 'dictionary words are not allowed'.
Of course this will frustrate ...
5
It all depends on context
My baseline advice is:
Do as Google does
Chances are that if they can compromise Google's OpenId security, they won't bother with you. Anything more secure than that needs to be backed up by a very strong added value proposition:
We want to be more secure than Google because ____________________
It is more valuable for our ...
5
Complex passwords are often enforced by an organization's IT department to ensure that the user accounts of employees aren't externally compromised. They're also enforced in situations where a user is trusted to have access that could be damaging in the wrong hands.
In this case, neither situation applies. Stack Exchange doesn't store any private data, and ...
5
The question specifically notes a requirement for "tight integration with 3rd party sites". So all the arguments about how unimportant SE accounts are is besides the point.
Also note that no one is forcing anyone to use this particular OpenID service. There are many to choose from. Differentiation on the basis of good security seems like a good idea for ...
4
I love how we are having this debate still in 2011. I wonder in another 10 years whether we will still be discussing the most appropriate password policy.
I agree with @Kyle-Cronin that the right way to approach this is to examine the risk:
What is the value? For standard users just the Stack Exchange (SE) account is of low-moderate value. It is not a a ...
4
You don't have to use an external service for OpenId. You could host an OpenId server internally and use it for your SSO. This would allow you to leverage open source code and all the work that has gone into making OpenId secure.
PS: OpenId can be used to have a unique identity used by many sites but you still have to "manually" login on each domain.
4
To some extent, what you suggest exists: it is called X.509 certificates.
The main problems with signed tokens are:
Control latency: once a token has been signed, it cannot be promptly canceled; you have to wait for expiration of the token. Or you implement an online revocation check (which is called OCSP in the case of X.509 certificates), which brings ...
3
If I'm understanding your example correctly, it sounds like you are talking about applying something like Kerberos to SSO. As long as the service provider knows how to trust the ticket granting authentication server, then yes, it should be secure.
As to why it is not done that way, I think it may be to provide greater control of information and keep it ...
3
First of all: CAS - http://www.jasig.org/cas :
Central Authentication Service project, more commonly referred to as CAS. CAS is an authentication system originally created by Yale University to provide a trusted way for an application to authenticate a user. CAS became a Jasig project in December 2004.
Second: no, I don't think it can do ...
3
No, CAS is just an Authentication Service, but you can surely impose Authorization using the mechanism, which is the base of doing authentication for your CAS.
Say, if you are using LDAP to authenticate the Accounts for CAS. Then, for the requirement like yours.....
You can create UserGroups in LDAP and assign respective User IDs to their groups.
Now, at ...
2
Imho the biggest concern with SSO is the sheer impact of a password breach, simply by factoring up all possible service accesses.
Otoh the younger history has shown that password reuse is more the rule than the exception. And SSO can also be used to enforce e.g. stricter password policies (use one password, but use it in a secure manner) or even enrich it ...
2
Perhaps ADFSv2 (A free download for Windows 2008R2) will help you with the common domain cookie. Here is an excerpt of the web.config located in C:\inetpub\adfs\ls that you will need to configure to achieve the desired effect.
<!--
Common domain cookie. A common domain cookie stores a list of recently visited Claims Providers
(also called ...
2
The short answer is No, it is not CAS's job to do Authorization, it is supposed to only to Authentication.
That said, there are many ways to use CAS in an Authentication/Authorization scenario. I am working on such a custom solution right now myself. I believe there are ways to do some spring security wizardry to get around to it, but the way I have it ...
2
Better or worse is relative to the usage of the protocol. SAML has it's place and SWT/JWT/et al have their place. The SAML spec is pretty much set in stone, whereas SWT/JWT are really in their infancy and keep changing.
SAML has lots of knobs which makes it fairly complex and that's the enemy of good security, but everyone pretty much implements it the same ...
2
It seems like it is probably equivalent to a throwaway account, although with less work involved. Another similar service that creates a disposable openid is at http://openid.anonymity.com/
Other services like myopenid.com allow you to create multiple aliases for a single account. Liquidid.net allows you to create multiple anonymous email aliases.
I guess ...
2
I do not think that it will be a good idea to hide the identity of Service provider(SP) from the Identity Provider (IdP- a trusted third party).
The IdP is providing authentication as a service to SPs that integrate with it.
This comes under federated identity management which is entirely dependent on establishing trust relationships between different ...
1
This SSO Design has a number of technical limitation that make it impossible to implement. There are security concerns with this design.
The worst vulnerability that this design implements is OWASP A9-Insufficient Transport Layer Protection. SSL must be used to protect all authentication information, therefore if you spill an authentication cookie over ...
1
At the end of the day I don't think really matters, since it's a preference of format.
SAML 2.0 is set in stone but is very large and verbose (as XML tends to be). But in my personal preference these days with my own projects. I say try out JWT tokens, which is a token in JSON format. If your client applications span across different platforms, it might be ...
1
The first two SF login scenarios, one of User1 and first one of User2 is possible simultaneously which is straight forward.
Before I go further about the last two logins, I am presuming the Custom App you've mentioned is also on Salesfore. From your question, you're already on closer side for a solution as for both logins you are using same IDP. This makes ...
1
The scenarios you mention would all be a problem with SAML and would be with just about any SSO method. If someone has root access on a server or has acquired the private keys, the security of the system is significantly if not completely compromised.
When you are delegating authentication, any compromise in trust can invalidate part or all of the ...
1
Trying to migrate legacy applications onto a SSO system is very difficult. Even just setting up new off-the-shelf applications for SSO can be near to impossible.
A more achievable option (which paves the way to a true SSO implementation, and therefore should at least be considered as a prerequisite) is to use a consolidated authentication / account ...
1
If you try to implement a SSO system you have to distinguish two fundamental different solutions:
Server side SSO: in this approach every server application must use a central authentication system like a LDAP or it must trust some kind of ticket like in Kerberos or SAML or the authentication must be done with some kind of certificate.
Client side SSO: in ...
1
Yes, you can combine several authentication methods using the Satisfy {any|all} directive.
To apply BasicAuth only on some URLs, matching a pattern:
SetEnvIf Request_URI ^/webservice/* do_basic_auth
<IfDefine do_basic_auth>
AuthName "Authentication"
AuthType Basic
AuthUserFile /somewhere/.htpasswd
Require valid-user
</IfDefine>
...
1
A lot of good answers here.
These are some good solutions:
OpenId
OAuth
SAML
ADFS
Local Storage
Though I don't think any of these are really trivial to implement, without learning a bit more about them.
Better yet would be implementing a proper web-SSO product - though it seems from your question that that is not an option (though I would urge you to ...
Only top voted, non community-wiki answers of a minimum length are eligible
