I want to build a SSO system for web applications, but I dont want to use any protocol, just a plain cookie and session. can I?
In a word, no.
The concept of SSO requires that a client either:
possess a verifiable identity / authorisation assertion (credential) that it can transmit to multiple relying parties, or
negotiate with a relying party for the relying party to receive a verifiable assertion "just in time" (i.e. during login), or
some combination of the above.
Since cookies are scoped to a single domain, you cannot build an SSO system with just cookies and browser sessions.
If you don't wish to use Kerberos there are various other SSO protocols.
Related
I have two web applications app.domain1.com which is a SPA with his own API on api.domain1.com and app.domain2.com) with each have their own authentication system and user accounts
and I need to authenticate the user from app.domain1.com from app.domain2.com. The goal is to simplify switching from one app to another without requiring the user to log into each application by re-entering their password. I'm the owner of one app only so It's not possible to put them behind a reverse proxy or so.
Example :
app.domain2.com redirect to app.domain1.com/connect/{JWT} -> app.domain1.com SPA extract the JWT and send it via ajax to api.domain1.com for validation and login.
I have looking for OAuth2 and OpenID Connect for these but OAuth2 is more about delegation of resource access than authentication and OpenID Connect needs an Identity Provider which seems incompatible with my use case where each app has his own authentication mecanism and where I could not add a central authentication server.
Ideally, I'd like to adhere to a standard protocol.
I thought I could expose an endpoint GET /connect/{JWT} on each app.
The JWT could contains an email which could identify the user account, app.domain1.com and app.domain2.com could then share the secret for validating the JWT has not be tampered
and could have a short validity duration.
This endpoint validate the JWT, verify if a user match the email inside the JWT and log the user in.
I'm not sure about the security considerations with these process and if there is any other options ?
Thx for your help.
In my opinion you should go with OIDC. That protocol is designed exactly for the feature you described here. You can have one of the apps act as the IdP, and the other will be a Relying Party. It depends on which technology you use for your apps, but in some languages there are libraries which will turn your app into an IdP.
You can think of some generic protocol to make that federated login work, but you will be better off using standards. This way you won't have to wonder what are the security implications for your solution - you have security considerations for OIDC described in the spec itself.
So i'm tasked with implementing SSO for our Windows application. Currently, after a user logs into the machine, he or she has to re-log in to our app when he or she loads the application. The application validates the user by querying a LDAP server.
What we're looking to have is for the user to automatically be logged into the app when they click on it. My understanding is that the LDAP authentication must still happen, but Im not exactly sure what the workflow would be, and how exactly we can validate a user without requiring them to re-enter a username / password. Note that this is not a web application so I can't use tools like SAML or OAuth (unless i'm mistaken about this too..?)
So my specific question is as follows:
Is it possible to use LDAP for SSO, and if so, how? Is it possible for me to authenticate a user with just his or her username, or is a password also required?
Any guidance would be appreciated, and am happy to provide further clarification if needed.
First of all, LDAP is a protocol, which you use to communicate with databases that implement this protocol.
So LDAP databases (commonly called directories) are ... databases and so do not provide SSO functionality.
To deploy a SSO solution, you need a SSO service. All your applications will have to be "compliant" with this service in a way or another.
The only way I can think of to make a "Windows SSO" without adding a third party application is that the applications can retrieve NTLM informations in requests made by the client and uses the user data to identify him. (but in term of security, I let you judge what you think about it ;) ) . See this php example
Some LDAP implementations, including OpenLDAP, provide some level of support the Generic Security Service Application Program Interface (GSSAPI) or SPNEGO (a specific GSSAPI implementation)
Although not trivial, it is possible to perform SSO from a "browser" that supports GSSAPI. AFIK, IE, Firefox, Safari and Chrome all provide some level of support for GSSAPI although each browser requires specific configuration (typically whitelisting of Servers).
There are many SSO Products that implement these features in a "probably" more secure and easier process than doing it yourself.
There are many known vulnerabilities details that have been exploited with GSAPPI/SPNEGO typically due to implementation issues.
I have a web service that acts as a OAuth 1.0a provider. Web applications go through the OAuth 1 workflow to gain access to user resources. So far so good.
The client web application has the need to communicate with the service for other needs, to exchange private data NOT linked to a particular user/resource owner. For that, a good idea seems to use OAuth2, in particular Client Credentials Grant (4.4)(which was designed exactly for this).
From a "confidential client" (and a web application falls into this category, according to the OAuth specs) you can directly authenticate your client and get an access token.
EDIT: of course, the kind of web application I am talking about is html+javascript BUT authentication and communication with the provider/web service happens entirely server-side. Credentials (client secret, keys, etc.) are all stored on (and never leave) the server.
According to the specs, authentication can happen with "username+password" (client password with HTTP Basic authentication scheme) or "other authorization methods".
I was not able to find any clue of what these "other authorization methods" may be.
Since we use private/public key pairs for OAuth1, can we use them for this task too?
The specs seem very liberal (and very vague!) on this point.
I would like something that is supported by the various libraries, so that a 3rd party client can implement it easily using standard libraries (like DotNetOpenAuth for example). If needed, it is reasonable to assume that some coding needs to be done for the custom method, as long as it can accommodate existing libraries (plugin?)
Is there anything "standard" or easily usable other than HTTP Basic, for OAuth 2 authentication?
If by web application you mean a JavaScript and HTML app that runs in the client browser and needs to make secure requests to your service, that is not a "confidential client". You cannot store secrets in a browser based app, as they will be visible to all.
If by web application you mean a server-side application that needs to make server to server requests, that is a "confidential client" because the executing code and secrets are not available to public scrutiny.
I interpret the "other authentication methods" to mean any authentication scheme that is customary over http (or https) that can be completed in one request. Client certificate authentication using TLS might also fall into this bucket. I think the main part of the OAuth2 4.4 Client Credentials Grant is that the client app presents credentials directly to the OAuth token service via existing authentication methods. The example uses HTTP Basic authentication, but that's just one example.
Client credentials grant differs from the resource owner credentials grant (4.3) primarily in that the resource owner grant presents the user credentials in the body of the http request instead of in the Authorization header. It would be difficult to use other authorization methods with resource owner grant.
The greatest caveat in using other authentication methods with the Client Credentials Grant is that support for anything other than HTTP Basic auth by OAuth2 client libraries will likely be spotty at best. Even if your use of digest or client cert auth with Client Credentials is within the OAuth2 spec, I'm doubtful that existing OAuth2 client libs will have built-in support for your particular permutation. See if you can find examples of client credentials grant using anything other than HTTP Basic auth by some of the big players such as Google or Yahoo. Things used there are more likely to be supported by OAuth client libs (especially the libs they ship!).
If you own both ends of the connection, this doesn't really matter. You can do whatever you want and find a client lib that will let you tweak or tailor the request to fit your needs.
If you want arbitrary clients to connect to your service using client credentials grant, you should plan on providing documentation and sample code of how clients should present the credentials you require. Off the shelf OAuth2 client libs probably won't provide automatic support for your scheme.
I am working on an internal authentication system for users of a set of of RESTful web applications. Our intention is that a user should be able to sign-on once via a web form and have appropriate access to all these RESTful applications in our domain, which may be distributed in a private cloud across many servers. (I understand already that having a single authenticated session is not aligned with a pure RESTful approach, but this is a usability requirement.)
The applications themselves will be written in a variety of programming languages so a language-neutral approach is required. It was suggested to me that we might use OpenID or OAuth or a similar framework to handle the authentication but my understanding is that these are intended for third-party services and not the first-party services that would share data on our internal system. In this case, we might have a central provider service with all the other applications treated as third parties (or relying parties).
Questions:
Are OpenID/OAuth suitable for authentication among first-party services?
If so, how would one be advised to set up authentication for this use case?
Wouldn't a user have to grant individual permission to each first-party server that they wanted to use, just as they would need to grant individual permission to any third-party server? I think this would violate the requirement of having a single sign-on for accessing all the first-party services.
Are there good examples of sites supporting this first-party use case?
What would be a good alternative framework for this first-party use case?
You do not need OAuth for SSO services.
The primary use/advantage of OAuth is, as you know already, granting access to a 3rd party app to access/use your resource in a controlled manner.
Rather than having an authentication/authorization server that you would need for OAuth, why not use a single log in service across all your APIs. An OAuth access token is totally different from what you need.
As far as I understand, what you can have is something like OAuth in a way that your server vends out tokens to the app. (I'm assuming that it's a totally internal system, so tokens cannot be misused).
So basically what I'm proposing is:
When an app tries to access the first API it's redirected to a web-form.
The user enters credentials and is taken to the DB for verification. Let there be a service that generates a token for the user/app
Next API access request would be made with that token - the token uniquely identifies the app
Depending on the level of security you need you can sign some text using HMAC and send it as token, or if its totally internal just generate a unique identifier for the app/user and send it to other API
On receiving the token, each service first calls the main server with the token and internally fetches the corresponding customer/user ID and performs the required function.
In short separate the login + token generation + token verification into a different module. All APIs should use this module for login/token verification.
What I have proposed here works like OAuth but all security aspects have been stripped down since you want to use it in a private cloud.
Oauth supports multiple different kinds of flows. You can use the client crendentials flow from Oauth 2.0 to avoid asking the user to grant permission for every app (this is intended for the cases where you control both the server and the app or where you want to preauthorize certain apps). This post does a good job explaining everything: http://tatiyants.com/using-oauth-to-protect-internal-rest-api/
I'm writing a web based application that will have its own authorization/authentication mechanism (traditional cookie/session based user/pass). However, depending on the organization that licenses the software, I want them to be able to plug in their own existing internal authentication system as a way to replace mine. Ideally, they'd have to run as little code as possible on their end; I'm trying to make this a mostly hosted service. I'm aware of the existence of OAuth, but don't entirely understand how I would go about implementing the system at a higher level. Any tips would be appreciated.
What platform are you developing for? PHP, Java, .NET, or other?
You should look into SAML and OpenID in addition to OAuth. These protocols are used for website to website authentication, more often than OAuth, which is mainly used for client applications on the desktop/mobile. It can be used but this is what people tend to use it for.
In general you are considered to be the service provider. The other organizations are identity providers. In SAML you would redirect a user to the identity provider who would authenticate (and possibly authorize) a user. They would be redirected back to the service provider which would then be able to log them in.
See the links from another post of mine for links to protocol documentation. Google Apps also have a good diagram of single sign-on with SAML in action.
Your question entangles the very things (authn/authz, i.e. policy, and application) that you want to disentangle. The answer you're looking for requires separating those concerns.
The "standard" answer is to separate authn/authz policy, typically using a PEP (policy enforcement point) to enforce decisions made by a PDP (policy decision point). SAML provides standards for communicating between the two.
You wind up with your application (and typically many others) guarded by the PEP. This can be embedded inside the application (for example as a Tomcat interceptor), but better, running in a separate container as a proxy. The only thing reachable from outside is the PEP. This examines each request, ensures the user is authenticated, and (for SSO) ensures that each request contains a security token.
If not, the PEP forwards the request to the PDP for authentication (login screen). The PDP attaches a security token and forwards the request back to the PEP. Since the request now has a valid token, the PEP forwards it to the application behind the firewall.