I'm wondering what strategies people use for reduced sign on with legacy applications and how effective they have found them?
We have an ASP.Net based intranet and own a lot of the legacy applications, but not all. We also have BizTalk and are considering the use of it's SSO engine too.
A good compromise between effort/rework and the convenience of single sign on is to continue to maintain a list of users, privileges, roles etc in the legacy app. Make the changes necessary to automatically log the user into your application based on their user account (usually their Windows or network account).
I'm currently running a couple of applications that use this method of sign on, and it makes them seem more integrated even though they aren't.
Another advantage we've found is that it stops people from sharing passwords to legacy applications. They're much less likely to hand out an admin password that also gives others access to their email or payroll details!
Multiple identity storage per application?
Might not be a single sign on solution, but have you try looking into something that is more targetted solution like MS Identity Lifecycle Manager? It will simplify identity synchronization between applications and it's pluggable as well, meaning you can hook up your own code to do the synchronization between different system. So if you change the identity info (i.e. login info) in ILM portal, you can propagate those to the different systems. Same thing for provisioning and deprovisioning identity. Single point of entry.
I supposed you can use biztalk also for similar thing.
As for truly single sign on solution where you just logged in once and you don't have to login again to different applications. I've yet to find one.
I supposed if your legacy apps has a pluggable identity provider module, it's doable, meaning you can customize the login system to hook up to your single identity source of truth whatever that maybe.
We did two things with legacy accounts. (legacy web based apps)
We first mapped the legacy accounts to their system logon accounts (running in a Windows Active Directory).
A facade logon screen then was applied to over the top of the legacy apps (web based), this would request the AD logon, which would then reverse map to the legacy applications logon account and assign the appropriate rights to the user, using the legacy systems security model. The user received a token for the session which kept the doors open for them.
This gave us the benefit of not having to retrofit legacy apps (for example what would happen is app x only had numbers for ID, and the user uses a windows logon (alphanumeric), and also achieve a psuedo single signon from the client's perspective.
The other option that did make sense was at the new logon screen, it would check multiple repositories of security, so even if the user didn't decide to use their windows logon they could still logon with the legacy account name. Obviously this does have some side effects but can also help ease the transition pain end users sometimes feel moving between systems.
There are also programs like the Citrix XenApp Single Signon which take a totally different approach to the issue.
In addition to Jimmy's points about using ILM, this particular system does allow integration with the AD PCNS (Password Change Notification Service) service, that can be used with ILM (ILM "sees" the password change event and can publish it to other consuming applications / services) to at least ensure that as a user's password changes in one system, it gets reflected into others.
Related
I am new to mobile programming although I have some experience of working on web products.
I have a few concepts which I need cleared...
What is the difference between an MBAAS(Like Kii or Parse) and a data store(like MongoDB)?
How will I tie MBaas and MongoDB together? Also, if i need to connect MBaas to an RDBMS how to go about it?
On some MBaas websites I read about objects in cache getting synchronised with objects in server etc. In what shape are these cached objects? Are they JSON bodys?
Can a session be shared between an application and a browser session in the same mobile ?
Can multiple applications access the same MBaas space ? What happens if multiple applications need to access the same data base? Is it possible ?
I have an application, can it use the same cache area for storing the ids/passwords of to different users ?
Please help me as I am not getting enough documents on the internet...
Thanks in advance,
Dee.
Those are all pretty good questions when you're starting to take a look at MBaaS. I'll try to answer according to my experience:
1) MBaaS provide a higher level of abstraction that a database. It delivers higher level services instead of just persistence. Think of services like user management, analytics, push, etc on top of just data management. MBaaS almost always provide a data management service but it's higher level since it runs on top of databases like MongoDB (since MBaaS services require scalability they often rely on NoSQL databases but they do not expose the db api to you directly). Pros: you get to deal with a simpler/straightforward data management api. Cons: you don't get granular control over the data operations as seen on a db
2) To tie MBaaS to other database you need to rely on the MBaaS import/export services (I suppose that this makes sense to you after reading the first question). Pros: you don't worry about how the data is stored in an MBaaS (it will scale, have integrity, etc). Cons: you don't have a low level access to the data (you do it through the MBaaS API). But I must say MBaaS are improving a lot in what they allow you to do with the data (this is getting better)
3) maybe you read something about the offline capabilities of some MBaaS. Some of them keep operations and/or changed objects in a cache and then synchronize with the backend when online. The shape of these can vary with each MBaaS but JSON is often used when it's time to communicate with the backend (JSON is convenient for transfers of data/operations but it's not necessarily an internal representation of MBaaS client cache)
4) Not in the traditional web sense of having a session with a cookie. MBaaS usually work at the level of a user session relying on authentication services (they are particluarly strong in this area). Some MBaaS provide an anonymous user functionality where users of your app can do a session without explicit authentication (but this can't be correlated to a the same user doing an anonymous session on the web). In general you'll have to use user authentication to share web activity with MBaaS activity.
5) On the first generation of MBaaS this wasn't possible. Everything was designed thinking in independent apps. But some problems started to arise like "what if I want to share users among different apps"? So MBaaS provides are adding more services that address this sort of issues (like single sign on for multiple apps)
6) I'm not sure if I follow but if you have an application that uses an MBaaS you're probably going to use the MBaaS authentication services to login a user so the fact that you're using one device/one cache is not an issue for allowing your app to authenticate multiple users. Let me now if this is not exactly what you asked (I can edit the question)
Hope this helps you get a better picture.
Best!
I have an encrypted connection from my ios app to my mysql database. My question is whether or not they would be able to intercept the connection form the ios app and find the domain with or without an encryption
whether or not they would be able to intercept the connection form the ios app
Yes, they would be able to do so. At least surely using a jailbroken device - for jailbroken devices, there are a couple of factors that make hacking easier.
On the one hand, on a jailbroken system, it is possible to prevent Apple's encryption of the app executable (by dumping the unencrypted program code from memory to the disk) and run a utility called "class-dump" to obtain the Objective-C class information (it is also possible to use the GDB debugger on the device or IDA Pro in order to reverse engineer the application logic).
On the other hand, the same MobileSubstrate library that is used for making iOS tweaks can be used to alter the behavior of any given application (I have successfully used this technique for circumventing some code obfuscation at runtime), so in theory an attacker would alter the communication logic of your application and dump the unencrypted data of yours and your users.
On the gripping hand, most standard and less-used Unix utilities usable for such kind of hacking are ported/compiled for jailbroken iOS - including the popular network sniffing tool nmap, the "John the Ripper" password cracker, the infamous aircrack-ng WEP/WPA key cracker, the GNU debugger (GDB), etc. These are also useful for executing an attack you described.
If the connection itself is encrypted, then, in theory, your data should be safe while in the wire. This still doesn't prevent the MobileSubstrate-based approach to exploitation. It is also true that the IP address of the server you're connecting to can be found relatively easily (end even the domain it is matching, since there are also known techniques for obtaining reverse-DNS information using a known IP address).
I'm not sure if this is possible without a jailbreak, but a similar man-in-the-middle attack was performed against Apple's in-app purchases by a Russian hacker (effectively rendering ineffective the underlying payment system and allowing purchases to be freely downloaded), merely by requiring users to install SSL certificates, profiles and using the hacker's own proxy server, so I'd suspect it is possible even without a jailbreak. Note that in this case the connection was also encrypted, and it was not the encryption that mattered.
You should not imo create a direct connection to the mysql-database but instead pursue a connection with a server program/api with a connection to the database in question. To answer the question more directly users should not be able to intercept the connection from the ios-app if it is encrypted correctly but still, is it worth that risk?
If the connection is encrypted, the data are secure. But not the domain. The iPhone is connecting to an IP Address, and that IP Address is obviously not encrypted.
Create a PHP interface between your app and the Mysql. Doing this they will be able to hack only app-accounts not the entire database! Your Mysql credential will be stored in the remote domain where the PHP code runs.
im struggling to find the best practice to this so any links or research reading materials or any Google search terms will be much appreciated.
Im a volunteer for a local charity organization, a childcare setting.
We have a mysql database that contains various tables containing children & Parent information, invoices, staff rotas etc.
What we would like to attempt to do is have secure online access for parents to view there own contact details and invoices.
My question is, is it safe to allow the website to have access to the main database. it would be a second set of userPermisions with only read access to select tables and not the entire database.
I don't want the website to open up a hole to allow users to obtain all our data or destroy or corrupt the main database.
Or
should i create a second database that the website will have access to and have the main database sync with the second? I can see future issues if we decide to allow parents to edit there own contact details, pay invoices online.
Web specific details will be kept in a second database such as user name password, forum etc
Its not any thing iv ever attempted to do before and don't know where to start in terms of research.
Kind regards
Matt
You certainly couldn't hurt anything by having a second, slave/read-only database accessible to your user interface. If done properly, MySQL grants can restrict users to read-only operations, so it's not necessary from a functional standpoint to have a second database. Perhaps, given the nature of your business, there may be a legal reason why you must have a second database though. Be sure to investigate the requirements for protecting PII (e.g. HIPPA)
Security is an ongoing process - part of it is ensuring proper identification and authorization as well as defense in depth - ensuring that the account used to access the database has least privileges and that the surface area exposed to that account is minimal. Also if the database is on the same machine as the web server, then ensuring that a compromise of the web server doesn't also compromise the database.
You also have to contend with the standard social elements - ensuring users have a way to get their first password/setup an account, maintain their own passwords. You should not store their passwords (even encrypted), but instead store only a salted hash. When they forget their password, the reset it themselves, since the web site cannot and should not send them a permanent password via email.
And you should be aware of XSS (cross-site scripting attacks), SQL injection - you should be able to find references to that in most discussions of web application development.
I am developing a swing based DEFECT TRACKER application.
The problem is I have to maintain user sessions. I do not have a clue how to do this. Many users may access the system simultaneously and enter their own data. This is a basic scenario seen at many places.
Like any login based application we have.
These are the following answers I can think of:
If the user logs in before performing any activity, you could easily maintain session information based on the login ID.
If there is no necessity for the user to login, you can track the clients connected at the entry point of your application and maintain a map of them. Since each user is not logging in explicitly, you might want to track the clients based on the IP address they are logging in from.
You could assign each Swing client downloaded an unique GUID and send that along with each request.
Of course, the caveat is if there are a lot of concurrent users accessing the system, you have to implement a queuing system and also make sure that your server code is thread safe.
A completely different approach is use to JSPs or Servlets.
I have a simple REST JSON API for other websites/apps to access some of my website's database (through a PHP gateway). Basically the service works like this: call example.com/fruit/orange, server returns JSON information about the orange. Here is the problem: I only want websites I permit to access this service. With a simple API key system, any website could quickly attain a key by copying the key from an authorized website's (potentially) client side code. I have looked at OAuth, but it seems a little complicated for what I am doing. Solutions?
You should use OAuth.
There are actually two OAuth specifications, the 3-legged version and the 2-legged version. The 3-legged version is the one that gets most of the attention, and it's not the one you want to use.
The good news is that the 2-legged version does exactly what you want, it allows an application to grant access to another via either a shared secret key (very similar to Amazon's Web Service model, you will use the HMAC-SHA1 signing method) or via a public/private key system (use signing method: RSA-SHA1). The bad news, is that it's not nearly as well supported yet as the 3-legged version yet, so you may have to do a bit more work than you otherwise might have to right now.
Basically, 2-legged OAuth just specifies a way to "sign" (compute a hash over) several fields which include the current date, a random number called "nonce," and the parameters of your request. This makes it very hard to impersonate requests to your web service.
OAuth is slowly but surely becoming an accepted standard for this kind of thing -- you'll be best off in the long run if you embrace it because people can then leverage the various libraries available for doing that.
It's more elaborate than you would initially want to get into - but the good news is that a lot of people have spent a lot of time on it so you know you haven't forgotten anything. A great example is that very recently Twitter found a gap in the OAuth security which the community is currently working on closing. If you'd invented your own system, you're having to figure out all this stuff on your own.
Good luck!
Chris
OAuth is not the solution here.
OAuth is when you have endusers and want 3rd party apps not to handle end user passwords. When to use OAuth:
http://blog.apigee.com/detail/when_to_use_oauth/
Go for simple api-key.
And take additional measures if there is a need for a more secure solution.
Here is some more info, http://blog.apigee.com/detail/do_you_need_api_keys_api_identity_vs._authorization/
If someone's client side code is compromised, they should get a new key. There's not much you can do if their code is exposed.
You can however, be more strict by requiring IP addresses of authorized servers to be registered in your system for the given key. This adds an extra step and may be overkill.
I'm not sure what you mean by using a "simple API key" but you should be using some kind of authentication that has private keys(known only to client and server), and then perform some kind of checksum algorithm on the data to ensure that the client is indeed who you think it is, and that the data has not been modified in transit. Amazon AWS is a great example of how to do this.
I think it may be a little strict to guarantee that code has not been compromised on your clients' side. I think it is reasonable to place responsibility on your clients for the security of their own data. Of course this assumes that an attacker can only mess up that client's account.
Perhaps you could keep a log of what ip requests are coming from for a particular account, and if a new ip comes along, flag the account, send an email to the client, and ask them to authorize that ip. I don't know maybe something like that could work.
Basically you have two options, either restrict access by IP or then have an API key, both options have their positive and negative sides.
Restriction by IP
This can be a handy way to restrict the access to you service. You can define exactly which 3rd party services will be allowed to access your service without enforcing them to implement any special authentication features. The problem with this method is however, that if the 3rd party service is written for example entirely in JavaScript, then the IP of the incoming request won't be the 3rd party service's server IP, but the user's IP, as the request is made by the user's browser and not the server. Using IP restriction will hence make it impossible to write client-driven applications and forces all the requests go through the server with proper access rights. Remember that IP addresses can also be spoofed.
API key
The advantage with API keys is that you do not have to maintain a list of known IPs, you do have to maintain a list of API keys, but it's easier to automatize their maintenance. Basically how this works is that you have two keys, for example a user id and a secret password. Each method request to your service should provide an authentication hash consisting of the request parameters, the user id and a hash of these values (where the secrect password is used as the hash salt). This way you can both authenticate and restrict access. The problem with this is, that once again, if the 3rd party service is written as client-driven (for example JavaScript or ActionScript), then anyone can parse out the user id and secret salt values from the code.
Basically, if you want to be sure that only the few services you've specifically defined will be allowed to access your service, then you only option is to use IP restriction and hence force them to route all requests via their servers. If you use an API key, you have no way to enforce this.
All of production of IP's security seems produces a giant bug to users before getting connected. Symbian 60s has the fullest capability to left an untraced, reliable and secure signal in the midst of multiple users(applying Opera Handler UI 6.5, Opera Mini v8 and 10) along with the coded UI's, +completely filled network set-up. Why restrict for other features when discoverable method of making faster link method is finally obtained. Keeping a more identified accounts, proper monitoring of that 'true account'-if they are on the track-compliance of paying bills and knowing if the users has an unexpired maintaining balance will create a more faster link of internet signal to popular/signatured mobile industry. Why making hard security features before getting them to the site, a visit to their accounts monthly may erase all of connectivity issues? All of the user of mobile should have no capability to 'get connected' if they have unpaid bills. Why not provide an 'ALL in One' -Registration/Application account, a programmed fixed with OS, (perhaps an e-mail account) instead with a 'monitoring capability' if they are paying or not (password issues concern-should be given to other department). And if 'not' turn-off their account exactly and their other link features. Each of them has their own interests to where to get hooked daily, if you'd locked/turn them off due to unpaid bills that may initiate them to re-subscribe and discipline them more to become a more responsible users and that may even expire an account if not maintained. Monthly monitoring or accessing of an identified 'true account' with collaboration to the network provider produces higher privacy instead of always asking for users 'name' and 'password', 'location', 'permissions' to view their data services. IP's marked already their first identity or 'finding the location of the users' so, it's seems unnessary to place it on browsers pre-searches, why not use 'Obtaining data' or 'Processing data.'