I'm building a website using service-oriented architecture (SOA) principles. When users visit the site in their browsers, the interface they see will be composed of resources delivered by several different services on the backend.
My question is how to use OpenID Connect (OIC) to implement SSO so that users log on through the site once and their browsers can automatically retrieve all the protected resources that are necessary.
The main conceptual difficulty I'm having is that everything written for implementing OpenID Connect seems to be oriented toward people creating monolithic third-party clients that authenticate with Google, Yahoo, etc. In my case, however, the client is my web portal and the resource providers are my backend services. Certain OIC concepts don't make sense to me in this context: for instance, the auth grant. Are users supposed to authorize the web portal to access their information the first time that they log on? That would be pretty absurd.
Or Is OIC the wrong tool for what I'm trying to do?
Related
This is a very basic question. I want to do an SSO integration using ColdFusion but do not know where to start. I found the website ssoeasy.com through a google search, but am very confused about how to use it and where to find documentation.
I think it has something related with cfldap or cfhttp but not sure what and where:
<cfhttp method="get" url="http://testsso.com/login.cfm">
</cfhttp>
It really depends on what role you want to play in an SSO ecosystem. Are you an app in a larger federation (Service Provider), or are you trying to implement an SSO style login across multiple applications that you control, or are you looking to setup so that your users can log in with Google or Facebook or such other identity registers?
A few years back we did an implementation with Shibboleth (https://shibboleth.net/) and CF where our intended place in the system would be that of a Service Provider to other companies Identity Providers. It works pretty straight forward as we let Shibboleth handle all the SAML federation grunt work and then when it's completed we get an e-mail address (the unique identifier we decided on) back from Shibboleth saying that the user has been authenticated via the Identity Provider.
Other 'SSO' implementations are around for other types of integrations.
From CFCs to handle OAuth -- https://github.com/coldfumonkeh/oauth2
To integrated oauth support if you're running a new enough version of ColdFusion https://helpx.adobe.com/coldfusion/cfml-reference/coldfusion-tags/tags-m-o/cfoauth.html
Hope this is of assistance to you.
If I understand your SSO use case, the application will be a cloud service provider (SP). There are three things you need to determine to help in the selection of the appropriate technology, mainly (1) SSO protocol to integrate, mainly SAML, OAuth, OpenID Connect (OIDC), etc. (2) Hosting, mainly Cloud, On-Prem, or hybrid, and (3) whether or not IdP discovery is needed for your business partners.
Being ColdFusion based as well as working to be a cloud SP web application, my experience is that the application is to be hosted by your organization, such that an on premise SSO capability is desired, as well as IdP Discovery will be needed for your partners.
As noted in your question there are some options for integration. I have found the most popular approach to being a SP website is to utilize a vendor product that handles the SSO protocol (e.g. SAML, OIDC) where the integration with your ColdFusion application is based upon a simple REST API integration. With this design pattern, the vendor product manages all the security of the SSO protocol and then simplifies integration to your application as a secure REST API exchange of identity information. This will minimize the impact to your application and also give the most support for modern identity. One product that offers this capability is PingFederate via the Agentless integration (also referred to as Reference ID integration). I have had much success integrating ColdFusion applications following this type of approach.
SAML seemed to be the easiest to implement for our team. Phil Duba's 2013 Beyond Encrypt() presentation is a good starting place. His website is down right now, but I'm sure you can find the downloadable file somewhere. Learning about SAML in general would be a good idea. Also, you can use Java, so maybe look at SAML/OAUTH Java examples and try doing that for Coldfusion since it is based on Java.
Im developing a java web application which is deployed on a glassfish server. The web services are used to connect to user databases. Each user has a database. My question is, is there a way to keep track of the user? For example in servlets we use sessions in order to store some user specific data. Is there something similar to it in web services? It seems impractical to have to authenticate the username and password each time the user sends a request to a web service. Thanks.
Web services may also use sessions, however there are good reasons to keep them stateless:
it might be that the clients do not support sessions (cookies), e.g. if your clients are not browser based;
stateless services are easier to scale.
You do not have to use username+password for authentication. You may use JWT (or other kind of access tokens) to protect them.
Auth0 has got nice article on this topic:
https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/
I'm going to integrate a Moodle-based application into my website wherein all data/activities being posted in this Moodle-based application can be retrieved by my website and vice versa.
So, is the Moodle web service enough to access all the data in that Moodle application?
Yes, you should be able to use web services. No, not all data is accessible out-of-the-box.
Things you can do with the webservices:
Retrieve a list of users, courses, assignments
Upload files
Create notes
Send messages
Enrol to courses, groups, cohorts
Check grades
On your Moodle site turn on web services and go to /admin/webservice/documentation.php to get a full list of existing functions you can call.
You can see some examples of this implemented in the Moodle Mobile App:
User: http://docs.moodle.org/26/en/Mobile_app
Dev: http://docs.moodle.org/dev/Moodle_Mobile
If these satisfy your requirements then yes web services should be sufficient as they are.
If they do not then you can extend the web services as a local plugin to provide richer functionality, which would be limited by your development capacity rather than the system itself. To port all of the features of some modules to web services would be a significant undertaking, but there are some low-hanging fruit to get activity lists, forum discussions/posts, choice polls, etc.
Web services is a better approach than exposing the database to an external system as it allows you to utilise the core APIs to improve integrity.
I am creating a service that will include a website, a mobile app, and a web service.
Both the website and mobile app will talk to the web service to interact with the database and any other backend items.
I would like users to be able to log in with other services (such as google, facebook, twitter, etc.)
I have two questions in implementing this:
1.) Should I use OpenID or OAuth? I'm not sure which is better for the situation. I have no need to actually access features from a users account, I just want them to be able to log in with accounts they already have,
2.) Where should I implement the authentication? Do I have to implement it both on the website and on the mobile app, or could I have both talk to the web service and do the authentication there?
Thanks
If you are just doing authentication and not syncing any account details, I think OpenID is the way to go. From a security standpoint, I would say to implement your authentication on the website and on the app and not in the webservice. You want to handle credentials the least amount possible and especially avoid sending the credentials via webservice if not using SSL.
We're in the early stages of designing a RESTful/resource-oriented web service API for a computational lingustics application. Because many of the resources we plan to serve are rights-encumbered, a key design decision has been to specify the platform so that each resource provider can expose their own web service that complies with the API spec. This way, the rights owner maintains control over their content (and thus the ability to throttle or deny access at will) and a direct relationship with the consumer, while still being able to participate in in the collaborative network.
At the same time, to simplify the job of writing a client for this service, we want to allow a client access to the distributed service through one end-point, with the server handling content negotiation and retrieval from the appropriate providers.
Right now, we're at an impasse on authentication/authorization schemes. One of our number has argued for the (technical) simplicity of a central authentication registry, but others are concerned about the organizational complexity of such a scheme.
It seems to me, based on an albeit limited understanding of the technologies, that a combination of OpenID and OAuth would do the trick, with a client authenticating with the end-point via OpenID, and the server taking action on the user's behalf with the various content providers using OAuth.
I've only ever seen implementations (e.g. stackoverflow, twitter, etc.) where a human was present to intervene, and I still need to do more research on these technologies.
Would a scheme like this work for an automated web service, or would it make the client too difficult to implement and operate?
OpenID does assume the user is present to drive a web browser to interact with their OpenID provider and do that initial authentication. But you could have the user authenticate to the end-point with OpenID, and there get an OAuth authorization for their client's automated use.
You should be able to do this without making the client too difficult to implement, particularly if the client is on a platform that allows it to spawn a web browser to drive that initial OpenID bit.