I am trying to wrestle with SSO in weblogic version is 12.2.1.3. We have integrated it with OAM/OID, within a larger application comprising of Oracle Forms & Reports. In addition to Forms, we have various custom servlet-based applications that need to be called from Forms.
This is fine.
Because authentication happens within the Oracle world, through OAM login screen, up to now I didn't have to mess with the Access Management within my Java custom code, apart from getting the username from HTTP headers.
The bad thing is that sometimes we need our servlets to act as middle-man between Forms and Reports. E.g. I need to call various stuff with Reports (on server), transform them and send them back to the client. I know that this doesn't sound right design-wise. But still it's legacy code and we need to make this work - at least need to try..
Previously we used to get away with it passing cookies between requests. But in 11/12g OAM, I am gathering from here that the cookie needed for successful session validation (OAMAuthnCookie) is stripped from the request before reaching my servlet. This seems to happen indeed, basing on the header dumps i am doing, and tracing calls using F12 Developer Tools on the browser.
So.. I have gathered that I need to generate a new OAMAuthnCookie, or something that would create it and attach it to the new http call.. I just would like an expert or somebody who has dealt with this to verify that the following assumption is right - the only way to do this is using OAM SDK (a bit non-intuitive imho).
Another thing - many of the examples that I find about OAM SDK deal with login forms. I don't need to do user authentication, nor do I need to talk with OAM myself to verify if the resource is protected or not. I am dealing with an already authenticated request - need to just somehow get UserSession and user token from HttpServletRequest, in order to generate new OAMAuthnCookie so that my next request (using e.g. apache client) succeeds.. I used to assume that this wouldn't be hard to do, but am a bit stumped now.
Thank you for your attention.
Working with OAM SDK, as far as I cursively saw (at the time of writing this, we were using Weblogic 12c with Access Manager that behaves exactly as described in the documents that talk about OAM 11g - therefore I assume that's the version we are using too), involves
generating ObAccessClient.xml from OAM Console, to establish contact between the code you are working on (which will be called Access Client), and OAM
including JARs from the downloadable OAM SDK with your application
writing code in your application (e.g. in authentication filter, or servlet) to establish communication with OAM via its SDK to finally authenticate/authorize etc.
There is a good guide about how to write the code in Oracle documentation here.
I found also these articles very informative:
Oracle Access Management blog
Oracle A-team Best Practices blog
The code that I had in mind would ultimately generate a new authentication cookie that I would pass to the reports servlet for further authorization (since this cookie is stripped indeed from the request before reaching my application). The only way I found to generate such a cookie would involve changing a setting in OAM console to include another cookie (OAM_IDENTITY_ASSERTION) in the requests, according to another Oracle A-Team article.
In the process of the above investigation, I finally stumbled on this magic reply to a question in Oracle forums. According to it, there is a user setting in OAM console, that allows to switch off the default filtering of OAMAuthnCookie.
filterOAMAuthnCookie=false
In our case, this perfectly suited me. Indeed after the change, the cookie in question was finally reaching my application, with the result of me being able to pass it to subsequent requests to Oracle Reports, without using OAM SDK.
I have made a Java EE 6 application where a user can browse a set of questions, add new questions and so on. The user can optionally log in so that he/she gets "credit" for adding the question or reporting it as bad.
Now I want to make a iPhone application where the user can do pretty much the same. So the answer is web service I assume. I have not worked with web service before but I see there are at least to alternatives: SOAP and REST.
Which one should I choose? I want the user to be able to log in from the application as well a as browse the questions in the database...pretty much many of the actions you can do on the web site.
I don't know much about the security and overhead they introduce.
Also I want the user to be able to retrieve the list of questions thorugh the web server and have the option to save it, so he/she won't need to have internet unless he/she wants to update it. Can I achieve this with both web services?
REST has less overhead than SOAP (WSDL contract, XML messages, supporting frameworks) so when the client is a mobile device REST seems more suitable. You could use JAX-RS (Jersey) to easily create REST services on the server side. The client request consists of the url structure and/or parameters like http://yourserver/questions/view/342 (to view question 342) or http://yourserver/questions/search?q=REST+vs+SOAP (to search for questions about REST vs SOAP). The response can be anything you want, but XML or JSON is pretty common.
Choosing REST means you will be leaning heavily on the HTTP protocol. For security a common approach is to use HTTP Basic authentication in combination with https. Basic authentication means you add an 'Authentication:' header to your HTTP request containing a Base64 encoded username:password pair. Note that Base64 does not encrypt anything, it just obfuscates. To avoid eavesdropping you need to use at least https meaning requests are encrypted using the server's public key. These requests can only be decrypted with the server's private key. To use https you need to set up the server with a certificate. If you want to avoid warnings about the certificate being 'untrusted' it needs to be issued by a recognized SSL certificate provider. For testing you can just generate it yourself.
Finally you asked about saving a list of questions for offline usage. This is a concern of the app, not of the service. To do this you need to store the retrieved data on the device and access that data if the device goes offline. I am not an iPhone developer, but I can imagine you could use a flat file or some lightweight database to store the data. When the device is offline, the app component that retrieves data should switch from network access to local storage access. Also some app functionalities like adding a question might need to be disabled. If you don't disable these, you would need to temporarily store any data entered by the user and send it to the server when the device comes online again. This could be a bit tricky to get right so my advice would be to leave this for later.
You can take a look at this previous SO post for some guidance. I would recommend using REST, it seems to be less messy than SOAP and Java has support available for it as shown here.
Through the use of annotations, you can simply created a facade to which users will connect. In turn, this facade will call the relevant logic which I am presuming you already have.
Well on a simple search REST vs SOAP, you will eventually get to this
There are plenty of other articles and even in-depth research papers, so it's only a matter of - do you really want to get serious with your research VS not really
Good luck!
Short answer: Yes, you can achieve that with web services.
Web services are only a facade to your system - they can expose (or not) any behavior you want to. If you have security concerns, you'll have to approach them anyway in both methods.
Personally, I'd use a RESTful approach as its usually simpler to implement and use. From Wikipedia:
A RESTful web service (also called a RESTful web API) is a simple web
service implemented using HTTP and the principles of REST. It is a
collection of resources, with four defined aspects:
the base URI for the web service, such as http://example.com/resources/
the Internet media type of the data supported by the web service. This is often JSON, >XML or YAML but can be any other valid Internet media type.
the set of operations supported by the web service using HTTP methods (e.g., GET, >PUT, POST, or DELETE).
The API must be hypertext driven.[11]
So you'd have a URL, say http://mywebsite.com/users and perform HTTP actions (GET, PUT, etc) on them. A GET request on /users/17 could return user 17, for instance, while a POST request on it would update said user.
As for login, when your users "log in" you would call a GET method that sends username:password (probably encrypted) and returns a login token. Every time the user executes an action, you would send said token with the request as an additional parameter.
I would like to build the following project:
public REST API back end which can be accessed by any authenticated client
front end with static files in HTML/CSS/Javascript with Backbone.js jQuery calls to the REST back end
In fact, there are three parties in my architecture : the front end, which is a client of the back end, the back end and the user which wants to authenticate on the front end login page.
What is the best way to secure the three parties involved in this architecture ?
In fact, I believe it is just impossible to do a secure app on the front end if I do everything in javascript, so I intend to delegate the authentication/authorization to a proxy layer on my server front end. What do you think about that ?
I intend to use OAuth to secure my REST back end, but I am not sure if I have to use the 2 or 3 legged implementation. What is the right approach in this case?
UPDATE : while searching a deep more on SO website, i found this thread which is exactly what i would like to do, except i want to use Java on server side and not DotNet. If i understand well, in fact my web site is like any client of my REST API, except it is the only one which has the right to create new users' accounts. Because, if my REST API is only accessible by OAuth (like Twitter's one), who can perform the user account creation before ? Am i right ?
One major concern with security with this architecture is testing. Automated tools will have trouble testing this system for common vulnerabilities like SQL Injection, Direct Object Reference. A useful tool for testing strange architectures is OWASP's open source Zed Attack Proxy or the proprietary BURP proxy. Testing will be time consuming and requires someone who has a good understanding of web application vulnerabilities. We often refer to these people as Pentesters.
A RESTful form of keeping session state is to use an HMAC to protect the values from modification. However, this is a misuse of cryptography because it opens the door for attack. An attacker can brute force the secret key used in your HMAC and then modify values such as his session id or otherwise gain access to another account on the system. Cryptography should only be used when there is no other option. This vulnerability is prevented entirely by storing session state in a database, which isn't RESTful.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed last year.
The community reviewed whether to reopen this question last year and left it closed:
Opinion-based Update the question so it can be answered with facts and citations by editing this post.
Improve this question
Warning! I'm on a bit of a fishing trip here, and I'm not even sure if the questions that I'm asking entirely make sense. Please be kind with your responses! :)
I recently took over a project that is currently based on a Java + Linux + Tomcat + MySQL. Right now, the system is basically just a website with a few cron jobs in the back-ground to move some data around, etc. In working with the product manager to develop a prioritized backlog, it’s clear from what he wants to do that I need to start developing a service-oriented architecture (SOA <-- buzz word warning!), and I will end up with a blend of web servers and application servers. Note: I’m strongly considering moving to Glassfish v3.
Currently, authentication and authorizations are handled in Java code with user information being stored in the MySQL database. At the bare minimum, it seems to me that I will need to split this out into a separate authentication service (otherwise, will end up with a bunch of duplicate code all over the place to handle user authentication and authorizations).
I’ve been looking into single sign-on (SSO) type solutions and doing some research. From what I can gather, OpenSSO has been officially dropped by Oracle, but picked up by ForgeRock and now is called OpenAM. This appears to be very close to what I want, but since I already have a MySQL-based system, I would prefer to have something that supports it (or some other kind of RDBMS). I found this on Stack Overflow and it seems to indicate that it’s basically LDAP or nothing.
Is there a way to make OpenSSO/OpenAM talk to Database for its authentication and authorization?
My questions are:
What other options are out there to OpenSSO/OpenAM? Is LDAP the way to go? Note: doing a “OpenAM vs” google search doesn’t yield much. Do people tend to just “roll their own”?
Any thoughts/suggestions/links on this topic that will help educate me will be greatly appreciated. Thanks in advance for your patience and help.
Are you integrating existing applications, or do you just want to support your own applications?
Are you looking for actual SSO or simply shared credentials? SSO is logging in to a single application, and having that credential propagate to another application (such as logging in to Gmail and being automatically logged in to Blogger). Shared credential is you can use the same login name and password across applications, but the credential itself is not automatically propagated.
LDAP is a common system used to manage a shared credential. Many systems allow you to point their authentication store to an existing LDAP server.
For example, if you had several apps deployed in a Java EE container, and also, say, an email server and web based email client, all of these diverse applications could be pointed to the same LDAP server and your users would have a single login and password for all of the different systems, all written in different languages, all deployed on different machines. This is a bread and butter use case of LDAP, and pretty much every system can handle this out of the box. Glassfish and Tomcat can both readily validate against an LDAP server. So can Apache (Web server), Postgres (Database), Postfix (email), etc. etc.
So if you want simply a shared credential, you get that "for free", right now, by installing an LDAP server. LDAP is a bit of a different beast than something like a DBMS, but once you study it a little and "get it", it's really quite nice. OpenLDAP is a popular LDAP server, but I'm partial to ApacheDS.
The way to set that up in a Java EE container is to set up a "Realm". GF and Tomcat both have LDAP realms out of the box, I imagine the rest do to. But the nut there is that you need to use Java EE security to leverage the Realm.
See, the detail with a Java EE Realm is that it's an aspect of the CONTAINER, not the application. Just like a connection pool is a container resource that your application leverages. Most people want security to be a part of their application, where they feel they have more control over it.
That's all well and good until you start getting a bunch of different applications and everyone is configured differently and has separate user lists, and password policies, etc. etc.
LDAP can fix a lot of that, since you configure them all to use the same credential store.
The Realm fills that need on a Java EE server. Your application is configured to use a Realm provided by the container. If you have several applications, and a single Realm, then they all get to share the credentials within that Realm (regardless of the Realm type).
Realms can be anything: file based, db based, LDAP, etc. Realms also cluster if the container clusters (which can be handy).
The dark side of Java EE security, and why most apps avoid it is that, since, again, the Realm is part of the container, and not the application, it can be a little ungainly to use, and perhaps not offer the features you like in terms of user management, password policies, etc.
But the bright side of Java EE security is that once you're under its umbrella, you can leverage the credential all over in your code easily. A person logs in to the web site, and that credential can be used there in the web app, or automatically propagated back to the EJB tier (ever a remote EJB tier), and the information is always handy.
You can point your web apps at a realm, you EJBs, your web services. They all leverage the same pieces.
In order to get kind of the best of both worlds is to leverage container specific mechanisms to access the containers security. This is the other dark side of Java EE security.
Things like Realms, and direct access to container security are not portable across containers. GF does it different than Tomcat does it different from WebLogic. It's all really close, but differs in details so your code won't port seamlessly.
The bright side is for in house apps, most folks simply leverage the container they have, put a reasonable abstraction around the container dependent code, and call it day noting that yes, they will have to port this if and when they move to a different container. But, in practice. much like a database, once a container platform is chosen, folks tend to snuggle in tight and stick with it.
Finally, Servlet 3.0 (In GF3 and Tomcat 7) standardizes more of the programmatic login issues to make them more portable across containers, but the underlying concepts are the same.
Now, SSO.
SSO is a different beast. But, out the gate, both GF and Tomcat support SSO for web apps. This lets you log in to one web app and have be able to easily access others without having to log in to them. But the SSO is a little bit limited since it relies more heavily on the container security and its lifecycle, rather than a more flexible one under the control of the application. Mind, not just on Realms (that's a given), but on the actual container based FORM login, rather than a custom programmatic login. FORM login is not spectacular, but it's functional and it works. Implement a Realm, deploy your apps to a single instance of Tomcat or GF (or a cluster in GF 3.1), and you get SSO for free, so if that's important, it's kind of nice really. It's usability is fine for back office apps, but not perhaps the public internet.
If you want a more sophisticated SSO solution, then you need look at custom implementations. OpenSSO is one of those, and it relies on SAML and the SAML web profile. However, there are others. There's CAS, Atlassian Cloud, Kerberos, and OAuth as well. Those are all using different protocols than SAML. If you want to stick with SAML you can also look at Shibboleth, or even SimpleSAML (SimpleSAML is a PHP server that acts as a SAML Identity Provider, among other things, but you still need a Service Provider within your applications).
Whatever protocol you choose, the process is basically the same (detailed here -- Cross Domain Login - How to login a user automatically when transferred from one domain to another).
But the devil is in the details. And, boy, are there devils.
All of these systems are complicated. SSO is complicated. For example, now that you have Single Sign On, what about Single Sign Out? What about Single Time Out? What about credential changes while users are logged in? What about an STS (Secure Token Service) for your Web Services? (STS offers a similar delegated authentication mechanism for web services.)
SAML introduces you to a whole lot of new vocabulary, and a lot of configuration. It's not readily picked up since the documentation isn't stellar and relies a lot on standards documents which talk to a higher level of generic things, and not to you and your application specifically.
If you don't need really need SSO, then you'll likely be content with something like a central LDAP store and going on from there.
All that said, as an example, our applications support both a DB and LDAP backend. They use Glassfish, and Java EE security. We completely control the user experience. We also support SSO via SAML (we wrote our own Identity and Service Providers), and we have both shared credentials via LDAP and SSO across Java and other applications, using our code and third party code. The bright side is this is all standards based. The dark side is that standards are communicated in english, and english is subject to interpretation.
I say this simply to say it can be done. I have also written ad hoc, back of the napkin SSO implementations, both same domain and cross domain (same domain is simple with a shared cookie) using simple Servlet Filters. Password policies, password recovery, keep alive timers, multiple window timeout and session management (that's a hoot), roles, privileges, etc. etc. Been there, done that.
Also, I would be remiss to not mention Spring and Spring Security which offers all of this on top of Spring. I have not used it (I'm not a Spring person), but those folks do know what they are doing so it's worth looking at.
Please note that "Is there a way to make OpenSSO/OpenAM talk to Database for its authentication and authorization?" is phrased wrong. The question details and answers only deal with the authorization aspect. OpenAM works great with a MySQL database of users and passwords (authentication), and can use it's hidden/embedded LDAP server for storing policies and other settings.
It sounds like you still need to flesh out your security model, but you will likely find you do not need something like OpenAM at all, and can just use container/framework provided security.
This list might provide a good starting point:
http://en.wikipedia.org/wiki/List_of_single_sign-on_implementations
with JOSSO and Shibboleth springing to mind.
OpenAM has two separate stores, a User Store, where users and all the accompanying properties are stored and a Configuration Store, which holds the configuration. There is a database User Store, which is available in OpenAM however I have never tried it. The SO question you were pointing to was referring primarily to the config store, which while LDAP only, is embedded in OpenAM (so doesn't require direct management).
Personally I am a fan of Tomcat over Glassfish, as it is a fast and light Servlet container, without all the associated bloat which goes with a full J2EE container.
You can use OpenAm with RDBMs. I am using JBDC based user store in OpenAm
OpenAM seems to have the ability to plug in your own authentication module.
Presumably, you can make your DB calls from within your extentsion of the AMLoginModule.
I have successfully build a custom user repository for OpenAm. Since this question have not been active for a while and because it would be too long to describe in details here how to do it, I will just give a few hints. If you need help on specifics, fell free to ask me.
Your basic entry point needs to extends com.sun.identity.idm.IdRepo.
You need to register your custom repository using ssoadm.jsp?cmd=add-sub-schema.
From this point, your repository type will be listed among the other types when you create a data store for a realm.
Good luck !
Here's a scenario:
I have a java front end (RCP/SWT) app which currently has no authentication support.
I have to however, add security to this application so that it gets deployed in different enterprise envinronments. I have a few approaches which I thought I would share with you all here and take your inputs. Please note that there are no strict requirements yet, so.. I would like you to consider typical and non-typical enterprise network security models.
Approach 1
Create a 'Security' webservice that
the thick client would invoke, on startup.
The client queries the security for the current authentication mode and receives the implementation class of the authentication as a soap attachment. The class received, will not have the logic for authencation, rather it would just describe the UI and the events on the UI. (The client could make use of a GUI toolkit such as Thinlet?)
Once the class is loaded, a UI relating to the currently set authentication method is displayed to the end user.
Advantages:
This approach lets me handle different authentication schemes. For instance, if the app has to authenticate against user names and passwords stored in a database, a screen with UserName and password fields would suffice. However, say the user were to do a network logon that would involved typing in the network name, the UI would contain three fields. If the security model at the client network dictates ntlm/SSO based authentications, the user won't see a UI. This will also leave scope for future authentication methods - for instance, supporting a captcha specific logon screen/ biometric stuff / whatever.
Approach 2
KISS (Keepin in yea.., Simple)
User name and password are usually the only two credentials required by all of the known authenticating mechanisms?
Have the thick client query the webservice and let the webservice handle the entire authentication process.
I am not sure how realistic/feasible/commonly used the above mentioned approaches are. Appreciate your help.
I'd certainly not recommend transmitting class definitions as SOAP attachments. A network classloader would make more sense, but is still not needed in your situation.
Put in the client what belongs there - the UI. Have the multiple screen types ready (i.e. defined as classes) on the client and activate each of them depending on a single value passed by the server. For example if AuthenticationType.CREDENTIALS is passed, go for username/password. If Authentication.SMART_CARD is - go for smart card.
If you want to distribute the application and later implement different auth screens, then use Java Web Start. Thus all clients will be guaranteed to be running the latest version.
After knowing that your requirements impose some limitations, take a look at this network classloaders article.