Many Lives Many Master - Best Ever Read

Book that is going to change your vision about cycle of Life and Death and "NEVER DIE BEFORE YOU DIE " attitude.

 

Here is the best of this book for which I feel

"We must share our knowledge with other people. We all have ability far beyond we use. Some of us find it out sooner than others. That you should check your vices before you come to this point . If you do not than you carry them over with you to another life. ONLY WE CAN RID OVERSELVES..OF THE BAD HABITS that we accumulate when we are in physical state(When we are living). The masters cannot do that for us. IF you fight and not to rid yourself then you will carry them over into another life. And only when you decide you are strong enough to master the external problems, then you will no longer them in your another life."

"We also must learn not just those people whose vibrations are the same as ours. It is normal to feel drawn to somebody who is on the same as outs. But this is wrong. You must also go to those people whose vibration are Wrong....with yours. This is the important ...in helping ...these poeple."

"We are given intuitive powers we should follow and not try to resist. Those who resist will meet to danger. We are not sent back from each plane with equal power. Some of us possess power greater than others, because they have been accrued from other times. THUS PEOPLE ARE NOT CREATED EQUAL. BUT EVENTUALLY WE WILL REACH A POINT WHERE WE WILL ALL BE EQUAL."

"People who are in coma are in state of suspension .They are not ready yet to cross into other plane.....Untill and unless they have decided whether they want to cross or not. Only they can decide this. If they feel they have no more learning ...in physical state... then they are allowed to cross over. But if they have more learning, then they must come back, even if they do not want to. The rest period for them , a time when their mental powers can rest"

"THE EXPERIENCE IS ALAWYS NECESSARY TO ADD EMOTIONAL BELIEFS TO INTELLECTUAL UNDERSTANDING"

-in simple word to convert INFORMATION INTO KNOWLEDGE , experience is REquiRED. 

What is NAT(Network Address Translation) with Example ?

Network Address Translation (NAT) -

It’s known that NAT (Network Address Translation) can ensure security since each outgoing or incoming request must go through a translation process that offers the opportunity to qualify or authenticate the request or match it to a previous request. NAT also conserves on the number of global IP addresses that a company needs and it lets the company use a single IP address in its communication with the world.

There are some other sticky network problems that need NAT (Benefit of NAT)

Static or dynamic translation

We’ve already mentioned that NAT cures duplicate address ranges without readdressing host computers. The translation done by NAT can be either static or dynamic. Static translation is where we specify a lookup table, and one inside address is turned into one pre-specified outside address. Dynamic is where we tell the NAT router what inside addresses need to be translated, and what pool of addresses may be used for the outside addresses. There can be multiple pools of outside addresses. ICMP host unreachable messages are used when addresses run out.

Port multiplexing

With NAT, multiple internal hosts can also share a single outside IP address, which conserves address space. This is done by port multiplexing: changing the source port on the outbound packet so that replies can be directed back to the appropriate machine.

Load distribution

You can also do load distribution via NAT: have one external address (perhaps your Web server’s name, www.cisco1900router.com, maps to this address). Then round-robin between different inside machines, so that incoming new connections are distributed across several machines. (Since each connection may involve state information, a given connection has to remain on one machine.)

Readdressing

Organizations that change service providers are now typically not allowed to take their address with them (because exceptions to CIDR addressing blocks have become a problem). NAT solves this by allowing re-addressing to occur at the gateway, allowing time to convert internal hosts to the new network number.

Additionally, NAT also enhances security—internal network topology and addresses are hidden from the outside world. The only thing NAT really can’t do much about is sloppily-written applications, with hard-coded raw IP addresses.

Disadvantages of NAT

Address translation is not practical for large numbers of internal hosts all talking at the same time to the outside world. NAT just won’t work well at a large scale.

Besides, performance may be a consideration. Currently, NAT only runs on Cisco 7500 routers with the RSP. Even there, NAT causes process switching on its configured interfaces. You can think of this as if the CPU has to look at every packet, deciding whether or not to translate it, and whether to alter the IP header, or possibly the TCP header. One doubts that this will be easily cache-able.

For more Reference :

http://www.cisco1900router.com/how-does-nat-work-benefit-v-s-disadvantages-of-nat.html

What is SSO(Single Sign On) in easy wording ?

What is SSO (Single Sign On)?

SSO (Single Sign On) means that when a user logs in to one application he will be "automatically" signed in to every other application, regardless of the platform, technology and domain.

For example, Google implements SSO for their products: Gmail, YouTube, Analytics, etc. When you turn on your computer and access Gmail, you login for the first time. Then, if you go to YouTube you won't be prompted for credentials again.

The way this works is by means of a "central service" (in the case of Google this is https://accounts.google.com). When you login for the first time a cookie gets created on this central service. Then, when you try to access the second application, you get redirected to the central service, but since you already have a cookie, you get redirected to the app directly with a token, which means you're already logged in.

Single-sign-on (SSO) is now required more than ever. In this two-piece post we will study how SSO is implemented for the web and provide a working example using OpenID Connect (in part 2). Read on!

---

Federated identity glossary

The concept of a centralized or linked electronic identity is known as federated identity. Federated identity systems handle several concerns:

• Authentication
• Authorization
• User attributes exchange
• User management

The authentication aspect deals with validating user credentials and establishing the identity of the user. Authorization is related to access restrictions (e.g., is the user allowed to access X resource?). The attributes exchange aspect deals with data sharing across different user management systems. For instance, fields such as "real name" may be present in multiple systems. A federated identity system prevents data duplication by linking the related attributes. Lastly, user management is related to the administration (creation, deletion, update) of user accounts. A federated identity system usually provides the means for administrators (or users) to handle accounts across domains or subsystems.

SSO is strictly related to the authentication part of a federated identity system. Its only concern is establishing the identity of the user and then sharing that information with each subsystem that requires the data. Below, we focus on this crucial aspect of a federated identity system.

Single sign on (SSO)

Sooner or later web development teams face one problem: you have developed an application at domain X and now you want your new deployment at domain Y to use the same login information as the other domain. In fact, you want more: you want users who are already logged-in at domain X to be already logged-in at domain Y. This is what SSO is all about.

The obvious solution to this problem is to share session information across different domains. However, for security reasons, browsers enforce a policy known as the same origin policy. This policy dictates that cookies (and other locally stored data) can only be accessed by its creator (i.e. the domain that originally requested the data to be stored). In other words, domain X cannot access cookies from domain Y or vice versa. This is what SSO solutions solve in one way or the other: sharing session information across different domains.

Different SSO protocols share session information in different ways, but the essential concept is the same: there is a central domain, through which authentication is performed, and then the session is shared with other domains in some way. For instance, the central domain may generate a signed JSON Web Token (which may be encrypted using JWE). This token may then be passed to the client and used by the authentication domain as well as any other domains. The token can be passed to the original domain by a redirect and contains all the information needed to identify the user for the domain requiring authentication. As the token is signed, it cannot be modified in any way by the client.

Whenever the user goes to a domain that requires authentication, he or she isredirected to the authentication domain. As the user is already logged-in at that domain, he or she can be immeditely redirected to the original domain with the necessary authentication token.

Different protocols

If you have been reading about SSO online, you have probably found that there are many different implementations: OpenID Connect, Facebook Connect, SAML, Microsoft Account (formerly known as Passport), etc. Our advice is to choose whatever is simplest for your development efforts. For instance, SAML is deeply entrenched in enterprise developments, so in some cases it will make sense to pick that. If you think you will need to integrate your development with more than one alternative, don't despair: there are frameworks that allow interoperability between different SSO solutions. In fact, that's one of the things we do at Auth0.

Aside: SSO with Auth0

If you are already using Auth0 in your developments, you know how easy it is to do SSO. If not, please see the docs on single sign on and check out the examples. Our SSO solution works as a bridge between different SSO frameworks. So whatever your existing apps are using, it has never been easier to integrate SSO into them. We do the hard work for you.

Conclusion

SSO is here to stay. Decentralized systems are becoming more and more common and authentication is an essential aspect of all of them. SSO solves a big problem: how to manage the increasing number of users across a whole ecosystem of applications and services. Frameworks such as OpenID Connect and services such as the one we provide at Auth0 make integrating Single Sign On into your new or existing applications much easier. If you are implementing authentication for a new application or service, consider integrating SSO from the get-go.

Reference Link:

https://auth0.com/blog/2015/09/23/what-is-and-how-does-single-sign-on-work/