Q1.What is conversational state? Define credentials.

Conversation State
One type of state that is likely to be relevant to a messaging system is the conversational
state. A Conversation is a sequence of coordinated message exchanges. The conversational
state defines where in that sequence of message exchanges a conversation is. For example, a
conversational state could be that component A has made a request and is now waiting for the
reply. Or, that component A has subscribed to events from component B with the
subscription due to expire in 10 minutes.

This state information is quite relevant and typically has to be shared between the
participants. There are also a number of different places where this state can be kept and a
discussion of where that should be is in fact quite relevant to designing a successful
integration or messaging solution. So where could part of this conversational state be kept?

TCP Stack

One equally popular and inefficient way to represent the state of the conversation is the TCP
stack. This happens when the architecture (ab)uses HTTP-based Web services calls as RPC's:
one component invokes a service, holding an open HTTP (read TCP) connection. In a
service-oriented environment it is likely that the service in turn accesses another service. As a
result, yet another TCP connection is established and held for the duration of this request-
reply interaction. Essentially, we built some form of distributed call stack via a set of open
TCP connections (see figure). The TCP stack is chartered with correlating incoming response
data packets to the right process waiting for a response. The advantage is that the application
process does not have to worry about correlation. The downside is that we use the TCP stack
as a surrogate call stack for a distributed system with long-running interactions. This can
quickly lead to a huge number of open connections, something a TCP stack is usually not
designed to handle. Also, we can easily imagine that a dropped connection can quickly bring
the house of cards down because the connections make up the conversation state.

In the Endpoints

In order to track more complex conversations a portion of the conversation state is typically
kept in the communication end points. In an asynchronous conversation, each conversation
partner has to "remember" what to do next once a message comes in. This implies that the
endpoint has to have some concept of how far the conversation is. For example, if a
component sent a request message it typically knows that it is waiting for a reply message.
Also, it might keep internal state data to be carried over to the processing of the reply
message. When the reply message arrives, the component uses the Conversation Identifier to
retrieve this state context.
Conversation Coordinator

In more complicated multi-party conversations, a conversation coordinator might be added

into the mix. The sole role of this coordinator is to track the conversation across the multiple
parties. In a multi-party conversation each individual participant may only have a partial view
of the conversation. A conversation coordinator may be required to make decisions that
require knowledge of the whole conversation. This model is commonly used to implement 2-
phase commit protocols using a transaction coordinator.

Managing Conversational State

Clients should view Web services as stateless and should assume that a service endpoint
retains no knowledge of previous client interactions. However, some use cases may require a
client to make a sequence of calls to a service to accomplish a given operation.

It is best if the client application maintains state when circumstances require this. The client
may manipulate this retained state when not online. There are ways for a client to identify
itself across multiple calls to a service and manage its state to keep it in sync with state on the
server.

Credential
A credential is an attestation of qualification, competence, or authority issued to an individual
by a third party with a relevant de jure or de facto authority or assumed competence to do
so.Examples of credentials include academic diplomas, academic degrees, certifications,
security clearances, identification documents, badges, passwords, user names, keys, powers
of attorney, and so on. Sometimes publications, such as scientific papers or books, may be
viewed as similar to credentials by some people, especially if the publication was peer
reviewed or made in a well-known journal or reputable publisher.

A few examples of credentials and their associated documentation are given below; this list is
far from exhaustive.

Diplomacy

In diplomacy, credentials are documents that ambassadors, diplomatic ministers provide to

the government to which they are accredited, for the purpose, chiefly, of communicating to
the latter the envoy's diplomatic rank. It also contains a request that full credence be accorded
to his official statements. The credentials of an ambassador or minister plenipotentiary are
signed by the chief of state, those of a chargé d'affaires by the foreign minister. Diplomatic
credentials are granted and withdrawn at the pleasure of the issuing authority, based on
widely varying criteria.

Medicine

In medicine, the process of credentialing is a detailed review of all permissions granted a

medical doctor at every institution at which he or she has worked in the past, to determine a
risk profile for trusting them at a new institution. Most medical practitioners also must have
credentials in the form of licenses issued by the government of the jurisdictions in which they
practice, which they obtain after suitable education, training, and/or practical experience.
Most medical credentials are granted for life, but may be withdrawn in the event of fraud or
malpractice by their holders.

Information technology

Credentials in information systems are widely used to control access to information or other
resources. The classic combination of a user account number or name and a secret password
is a widely-used example of IT credentials. An increasing number of information systems use
other forms of documentation of credentials, such as fingerprints, voice recognition, retinal
scans, X.509 Public key certificate, and so on.

Operator licensing

Operators of vehicles such as automobiles, boats, and aircraft must have credentials in the
form of government-issued licenses in many jurisdictions. Often the documentation of the
license consists of a simple card or certificate that the operator keeps on his person while
operating the vehicle, backed up by an archival record of the license at some central location.
Licenses are granted to operators after a period of successful training and/or examination.

Cryptography

Credentials in cryptography establish the identity of a party to communication. Usually they

take the form of machine-readable cryptographic keys and/or passwords. Cryptographic
credentials may be self-issued, or issued by a trusted third party; in many cases the only
criterion for issuance is unambiguous association of the credential with a specific, real
individual or other entity. Cryptographic credentials are often designed to expire after a
certain period, although this is not mandatory. An x.509 certificate is an example of a
cryptographic credential.

Identification

Credentials that simply establish a person's identity are very widely used. Documentation
usually consists of an identity card (sometimes a credential that is also used for other
purposes, such as an automobile driver's license), a badge (often machine-readable), etc.,
issued by a trusted third party after some form of identity verification. Many identification
documents use photographs to help ensure their association with their legitimate holders.
Some also incorporate biometric information, passwords, PINs, and so on to further reduce
the opportunities for fraud. Identification credentials are among the most widely counterfeited
credentials.

Security clearances

In military and government organizations, and some private organizations, a system of

compartmenting information exists to prevent the uncontrolled dissemination of information
considered to be sensitive or confidential. Persons with a legitimate need to have access to
such information are issued security clearances, which can be tracked and verified to ensure
that no unauthorized persons gain access to protected information.

Journalism

Some countries impose restrictions on who may work for the press or in a journalistic
capacity, and require that anyone allowed to do so carry a government-issued credential. This
allows these countries to exert a substantial amount of control over freedom of the press, by
selectively granting, withholding, and withdrawing press credentials.

In the United States, for example, no national press credential exists because it has been held
to violate the freedom of press provisions of the country's constitution, but individual
government entities (such as the White House and the military) and many non-government
entities issue and require press credentials for their own spheres of influence.

Trade credentials

Some trades and professions in some jurisdictions require special credentials of anyone
practicing the trade or profession. These credentials may or may not be associated with
specific competencies or skills. In some cases, they exist mainly to control the number of
people who are allowed to exercise a trade or profession, in order to control salaries and
wages.

Persons acting as merchants, freelancers, etc., may require special credentials in some
jurisdictions as well. Here again, the purpose is mainly to control the number of people
working in this way, and sometimes also to track them for tax-reporting or other purposes.

Academic credentials

The academic world makes very extensive use of credentials, such as diplomas, certificates,
and degrees, in order to attest to the completion of specific training or education programs by
students, and to attest to their successful completion of tests and exams.

Documentation of academic credentials usually consists of a printed, formal document

designed to last a lifetime without deterioration. The issuing institution often maintains a
record of the credential as well. Academic credentials are normally valid for the lifetime of
the person to whom they are issued.

Internet ID

Since the launch of "people" search engines and social networking sites, which look for
people instead of websites, problems with spamming and identity theft have created a
renewed need to verify credentials online.

Many companies now search the web for indications about their future employees[1]. Human
resource management (HRM) at many companies has taken an interest at sites, blogs and
profiles of potential candidates.

In the USA there are companies offering to correct "past mistakes" made by people in form
of negative comments of or about them.

Q2.What is Authentication? How it is differ from authorization?

Define authorization constraint.

Authentication is the process of determining whether someone or something is, in fact,

who or what it is declared to be. In private and public computer networks (including
the Internet), authentication is commonly done through the use of logon passwords.
Knowledge of the password is assumed to guarantee that the user is authentic. Each
user registers initially (or is registered by someone else), using an assigned or self-
declared password. On each subsequent use, the user must know and use the previously
declared password. The weakness in this system for transactions that are significant
(such as the exchange of money) is that passwords can often be stolen, accidentally
revealed, or forgotten.

For this reason, Internet business and many other transactions require a more stringent
authentication process. The use of digital certificates issued and verified by a Certificate
Authority (CA) as part of a public key infrastructure is considered likely to become the
standard way to perform authentication on the Internet.

Logically, authentication precedes authorization (although they may often seem to be

combined).

Authentication vs. Authorization

It is easy to confuse the mechanism of authentication with that of authorization. In many

host-based systems (and even some client/server systems), the two mechanisms are
performed by the same physical hardware and, in some cases, the same software.

What, then, distinguishes these two mechanisms from one another?

Authentication is the mechanism whereby systems may securely identify their users.
Authentication systems provide an answers to the questions:

Who is the user?

Is the user really who he/she represents himself to be?

An authentication system may be as simple (and insecure) as a plain-text password

challenging system (as found in some older PC-based FTP servers) or as complicated as the
Kerberos system described elsewhere in these documents. In all cases, however,
authentication systems depend on some unique bit of information known (or available) only
to the individual being authenticated and the authentication system -- a shared secret. Such
information may be a classical password, some physical property of the individual
(fingerprint, retinal vascularization pattern, etc.), or some derived data (as in the case of so-
called smartcard systems). In order to verify the identity of a user, the authenticating system
typically challenges the user to provide his unique information (his password, fingerprint,
etc.) -- if the authenticating system can verify that the shared secret was presented correctly,
the user is considered authenticated.

Authorization, by contrast, is the mechanism by which a system determines what level of

access a particular authenticated user should have to secured resources controlled by the
system. For example, a database management system might be designed so as to provide
certain specified individuals with the ability to retrieve information from a database but not
the ability to change data stored in the datbase, while giving other individuals the ability to
change data. Authorization systems provide answers to the questions:

Is user X authorized to access resource R?

Is user X authorized to perform operation P?

Is user X authorized to perform operation P on resource R?

Authentication and authorization are somewhat tightly-coupled mechanisms -- authorization

systems depend on secure authentication systems to ensure that users are who they claim to
be and thus prevent unauthorized users from gaining access to secured resources.

Figure , below, graphically depicts the interactions between arbitrary authentication and
authorization systems and a typical client/server application.
Authorization Constraints
Constraints are an important aspect of role-based access control (RBAC) and its
different extensions. They are often regarded as one of the principal motivation behind
these access control models. In this paper, we introduce two novel authorization
constraint specification schemes named as prohibition constraint scheme and obligation
constraint scheme. Both of them can be used for expressing and enforcing authorization
constraints. These schemes strongly bind to authorization entity set functions and
authorization entity relation functions, so they can provide the system designers a clear
view about which functions should be defined in an authorization constraint system.
Based on these functions, different kinds of constraint schemes can be easily defined.
The security administrators can use these functions to create constraint schemes for
their day-to-day operations. The constraint system can be scalable through defining
new functions. This approach goes beyond the well known separation of duty
constraints, and considers many aspects of entity relation constraints.

Q3.What is fatal error? What is filter chain? What is the Use Of it.

Fatal Error
In computing, a fatal error is an error which causes a program to abort - and thus may
return the user to the operating system. When this happens, data that the program was
processing may be lost. A fatal error occurs typically in any of these cases:

An illegal instruction has been attempted

Invalid data or code has been accessed

The privilege level of an operation is invalid

A program attempts to divide by zero. (Only for integers; with the IEEE floating point
standard, this creates an infinity instead)

In some systems, such as Microsoft Windows, a fatal error causes the operating system
to create a log entry or to save an image (core dump) of the process.

Filter Chain
A FilterChain represents a collection of one or more filters that can be appled to a Task
such as the <copy> task. In the case of the <copy> task, the contents of the copied files
are filtered through each filter specified in the filter chain. Filtering occurs in the order
the filters are specified with filtered output of one filter feeding into another.

:--------:--->:----------:--->:----------: ... :----------:--->:--------:

:.Source.:--->:.Filter 1.:--->:.Filter 2.: ... :.Filter n.:--->:.target.:

:--------:--->:----------:--->:----------: ... :----------:--->:--------:

A list of all filters that come with NAnt is available here.

The following tasks support filtering with a FilterChain:

<copy> task

<move> task

Parameters

Attribute Type Description

Required

encoding Encoding Deprecated. The encoding to assume when filter-copying

files. The default is system's current ANSI code page. False

id string The ID used to be referenced later.

False

refid string The ID to use as the reference.

False

Nested Elements:

<filter>

The filters to apply.

Allows a file's content to be modified while performing an operation.

Parameters
Attribute Type Description
Required

if bool If true then the filter will be used; otherwise, skipped. The
default is true. False

unless bool Opposite of if. If false then the filter will be executed; otherwise,
skipped. The default is false. False

</filter>

Examples

Replace all occurrences of @NOW@ with the current date/time and replace tabs with
spaces in all copied files.

<property name="NOW" value="${datetime::now()}" />

<copy todir="out">

<fileset basedir="in">

<include name="**/*" />

</fileset>

<filterchain>

<replacetokens>

<token key="NOW" value="${TODAY}" />

</replacetokens>

<tabstospaces />

</filterchain>

</copy>

Use of Filters
Filters can perform many different types of functions. We'll discuss examples of the
italicized items in this paper:

Authentication-Blocking requests based on user identity.

Logging and auditing-Tracking users of a web application.

Image conversion-Scaling maps, and so on.

Data compression-Making downloads smaller.

Localization-Targeting the request and response to a particular locale.

XSL/T transformations of XML content-Targeting web application responses to more

that one type of client.

These are just a few of the applications of filters. There are many more, such as
encryption, tokenizing, triggering resource access events, mime-type chaining, and
caching.

filters can also perform the following types of tasks:

Querying the request and acting accordingly

Blocking the request and response pair from passing any further.

Modifying the request headers and data. You do this by providing a customized version
of the request.

Modifying the response headers and data. You do this by providing a customized
version of the response.

Q4.Use Of Cookie ,show one real-time scenario where cookie use.

Problem of cookie

Cookie
Cookies are pieces of data created when you visit a website, and contain a unique,
anonymous number. They are stored in the cookie directory of your hard drive, and do not
expire at the end of your session.
Cookies let us know when you return to our website and what pages or services you use when
you're there. Our cookies aren't used to store or collect any personal information. It only lets
us know that someone with your unique cookie has returned to our website.
By using cookies we will be able to see how our website is being used. This means we'll be
able to identify the most popular areas of our website and make it easier for you to access
them. Cookies help us to be more efficient as we can learn what information is important to
our customers and what isn't.

Use of Cookie

So why would anyone want to store 4000 characters of text on a user's computer? It isn't
enough to put anything really worthwhile on there! The power of the cookie, though, is to
recognise a site visitor over and over again. To give just a few uses of cookies:

Many portals and search engines use them to provide customized pages and results to their
users, allowing such features as 'My Yahoo' etc.

Many websites use cookies to log their users in automatically. By storing a few pieces of user
information they can automatically authenticate the user's details and use them to save the
user time when they log in>/li>

Visitor tracking and statistics systems often use them to track visitors. By assigning the
visitor a cookie, they will not be counted more than once, so accurate unique visitor statistics
can be obtained. Also, if a user has a unique cookie the system can 'follow' them through a
website, showing the webmaster exactly where the visitor has been, and in what order.

real-time scenario where cookie use

The blooming e-commerce is demanding better methods to protect online users' privacy,
especially the credit card information that is widely used in online shopping. Holding all
these data in a central database of the web sites would attract hackers' attacks, impose
unnecessary liability on the merchant web sites, and raise the customers' privacy concerns. In
this paper we introduce and discuss in details the secure distributed storage of sensitive
information using HTTP cookie encryption. We are able to employ One-Time Pads to
encrypt the cookies, because encryption and decryption are both done by the server, which is
an interesting characteristic overlooked by the existing systems. We implemented this
protocol and showed that it is simple, fast and easy to program with.

Problems with Cookies

Cookies are not a perfect state mechanism, but they certainly make a lot of things possible
that would be impossible otherwise. Here are several of the things that make cookies
imperfect.

People often share machines - Any machine that is used in a public area, and many
machines used in an office environment or at home, are shared by multiple people. Let's say
that you use a public machine (in a library, for example) to purchase something from an
online store. The store will leave a cookie on the machine, and someone could later try to
purchase something from the store using your account. Stores usually post large warnings
about this problem, and that is why. Even so, mistakes can happen. For example, I had once
used my wife's machine to purchase something from Amazon. Later, she visited Amazon and
clicked the "one-click" button, not realizing that it really does allow the purchase of a book in
exactly one click.

On something like a Windows NT machine or a UNIX machine that uses accounts properly,
this is not a problem. The accounts separate all of the users' cookies. Accounts are much
more relaxed in other operating systems, and it is a problem.

If you try the example above on a public machine, and if other people using the machine have
visited HowStuffWorks, then the history URL may show a very long list of files.

Cookies get erased - If you have a problem with your browser and call tech support,
probably the first thing that tech support will ask you to do is to erase all of the temporary
Internet files on your machine. When you do that, you lose all of your cookie files. Now
when you visit a site again, that site will think you are a new user and assign you a new
cookie. This tends to skew the site's record of new versus return visitors, and it also can make
it hard for you to recover previously stored preferences. This is why sites ask you to register
in some cases -- if you register with a user name and a password, you can log in, even if you
lose your cookie file, and restore your preferences. If preference values are stored directly on
the machine (as in the MSN weather example above), then recovery is impossible. That is
why many sites now store all user information in a central database and store only an ID
value on the user's machine.

If you erase your cookie file for HowStuffWorks and then revisit the history URL in the
previous section, you will find that HowStuffWorks has no history for you. The site has to
create a new ID and cookie file for you, and that new ID has no data stored against it in the
database. (Also note that the HowStuffWorks Registration System allows you to reset your
history list whenever you like.)

Multiple machines - People often use more than one machine during the day. For example, I
have a machine in the office, a machine at home and a laptop for the road. Unless the site is
specifically engineered to solve the problem, I will have three unique cookie files on all three
machines. Any site that I visit from all three machines will track me as three separate users. It
can be annoying to set preferences three times. Again, a site that allows registration and
stores preferences centrally may make it easy for me to have the same account on three
machines, but the site developers must plan for this when designing the site.

If you visit the history URL demonstrated in the previous section from one machine and then
try it again from another, you will find that your history lists are different. This is because the
server created two IDs for you, one on each machine.

There are probably not any easy solutions to these problems, except asking users to register
and storing everything in a central database.

When you register with the HowStuffWorks registration system, the problem is solved in the
following way: The site remembers your cookie value and stores it with your registration
information. If you take the time to log in from any other machine (or a machine that has lost
its cookie files), then the server will modify the cookie file on that machine to contain the ID
associated with your registration information. You can therefore have multiple machines with
the same ID value.