text:
Systems and methods for state-less authentication
Systems and methods for providing user logon and state-less authentication are described in a distributed processing environment. Upon an attempted access by a user to an online resource, transaction, or record, a logon component asks the user to supply a logon ID and a password. The logon component verifies the provided information, and upon successful identification, a security context is constructed from information relevant to the user. The security context is sent to the user and is presented to the system each time the user attempts to invoke a new resource, such as a program object, transaction, record, or certified printer avoiding the need for repeated logon processing.
This invention is a continuation of prior U.S. patent application Ser. No. 11/325,463, filed Jan. 5, 2006, which is a continuation of prior U.S. patent application Ser. No. 09/839,551, filed Apr. 19, 2001 now U.S. Pat. No. 7,020,645, issued Dec. 5, 2002. This invention relates to authentication of users of electronic information and transaction processing systems, and more specifically to systems and methods for authenticating users of programs objects in distributed computing environments based on negotiated security contexts.
This invention relates to authentication of users of electronic information and transaction processing systems, and more specifically to systems and methods for authenticating users of program objects in distributed computing environments based on negotiated security contexts.
Many computer and communication systems restrict access to authorized users. As typically shown in
The logon component 122 compares the logon ID and password received from the user to an archive of logon IDs and passwords stored in a rules database 126. Upon finding a match with the forwarded logon ID, the logon component 122 retrieves the corresponding password from the rules database 126 and compares the retrieved password with the password forwarded by the user 110. If the passwords match, the logon component 122 sends an instruction or a message via the application server component 124 to the client application in computer 130 that indicates that the user 110 was properly identified and authenticated to proceed. This authentication step and/or subsequent instructions or messages may initiate a secure communication session using a convenient protocol such as https indicated by connection 150. Subsequent communication between the system 120 and computer 130 can then proceed in private.
Where encryption is employed, a client cryptographic token such as an electronic circuit card conforming to the standards of the PC Memory Card Interface Association (a PCMCIA card or PC Card) can be used in the computer 130. In general, a token is a portable transfer device that is used for transporting keys, or parts of keys. It will be understood that PC Cards are just one form of delivery mechanism; other kinds of tokens may also be used, such as those conforming to RSA Laboratories' software token Public-Key Cryptography Standard (PKCS) #12, floppy diskettes, and Smart Cards.
If the logon ID provided by the user 110 does not match an ID in the rules database 126 or if the password comparison fails, the logon component 122 typically sends a message or instruction through the application server component 124 to the client application to inform the user 110 that the submitted logon information was incorrect and to prompt the user to re-enter it. This process of entering and attempting to verify the logon information may be permitted to occur a few times, but in the event of repeated failure, the logon component 122 may finally reject further logon attempts by the user 110, direct the client application to inform the user 110 that the logon process has failed, terminate the communication session, and lock out the user from any further logon attempts.
A password is one form of identification that may be presented to the logon component 122 that authenticates the user's access rights, which may range from simply viewing selected records in the system 120 to performing all transactions permitted by the system 120. This kind of secured transaction processing is typically "state-full" in that it maintains, in the transaction session, the process state and content of the user's logon access information. Different transactions are typically implemented in modern distributed, nested, transaction processing systems by different program objects, e.g., applications or subroutines, that are substantially independent, even to the extent of executing on different processor hardware. For a user to migrate from one secured transaction to another, which is often necessary for even simple uses of today's systems, the user is generally required to logon (i.e., be authenticated) to each transaction, often with ID's and passwords unique to each transaction. This is because state-full systems impose state routing restrictions on users, and only sessions with particular restrictions can service a given user without having to close one program object and open another, with the corresponding requisite logon.
Besides the burden on system resources imposed by each logon, which requires access to and processing by a logon component and a rules database, state-full systems often compel each user to close one secured transaction (program object or application) before entering another, limiting the flexibility of the system from the user's perspective. In addition, if the path to the rules database is closed or if excessive traffic slows processing or access to any of the necessary components of the system, the user access to the desired application is compromised, even if the user's access is fully authorized. This becomes a significant problem for systems having many potential users because economics often limits the system resources that can be made available.
Another problem is that conventional enrollment systems can be viewed as "open doorways" into an otherwise protected application in that a successful logon provides a user full access to the application and a failed logon "slams the door" on access to the application. No middle ground is generally provided, whereby a properly identified user is provided partial access to an application or transaction.
Yet another problem with systems like that depicted in
In this application, "privacy" means the protection of a record from unauthorized access. "Integrity" means the ability to detect any alteration of the contents of a record or of the relative authority of a user to perform a transaction or access a record. "Authentication" means verification of the authority of a user to perform a transaction, use a system resource, or access an electronic record. It will be appreciated that "electronic record" and "record" mean information in any electronic form, regardless of type of medium or type of information. Thus, a record can be a tape cartridge, a voice transmission or recording, a video image, a multi-media object, a contract, metadata, a database of information, etc.
Integrity and authentication of information are typically handled by other cryptographic operations, in particular hashing the information to be protected and appending one or more digital signatures. In general, a one-way cryptographic function operates on the information and produces a "hash" or "message digest" in a way such that any change of the information produces a changed message digest. Since a different message digest is produced if even one bit of the information object is changed, the hash operation yields a strong integrity check. Known hashing algorithms are the Secure Hash Algorithm (SHA-1) and the Message Digest 5 (MD-5) algorithm, and new algorithms appear from time to time. Information is typically digitally signed by hashing the information, encrypting the resulting hash using the signer's private key, and appending the encrypted hash to the information. Thus, digital signatures are generated in a manner like PKC, but the keys are reversed: the encryption key is private and the decryption key is public; the digital signer signs information with the private key and a user can read the digital signature with the signer's public key. Since a digital signature is a non-forgeable data element attached or allocated to information that ties the signer to the information, the digital signature yields an authentication check. It will be appreciated that a digital signature differs from a holographic, or handwritten, signature and from a digitized holographic signature, which is a handwritten signature that has been captured electronically.
The uses of digital signatures typically involve uses of authentication certificates, which are non-forgeable, digitally signed data elements that bind the signers' identity information to the signers' public-key information. Authentication certificates have been standardized by the International Telecommunications Union (ITU) under International Standard X.509, as documented in "The Directory-Authentication Framework" (1988) and as interpreted by the Internet Engineering Task Force Public Key Infrastructure X.509 recommendations. An authentication certificate is digitally signed and issued by a Certification Authority that is responsible for ensuring the unique identification of all users. Each authentication certificate typically includes the following critical information needed in the signing and verification processes: a certificate version number, a serial number, identification of the Certification Authority that issued the certificate, identifications of the issuer's hash and digital signature algorithms, a validity period, a unique identification of the user who owns the certificate, and the user's public cryptographic signature verification key. A signer's authentication certificate may be appended to information to be protected with the user's digital signature so that it is possible for others to verify the digital signature.
Single-logon methods have been implemented in which a logon component returns a "cookie" or token to a client application that allows the client application system-wide logon in a distributed computing environment. One example of this is the SITEMINDER software product made by Netegrity, Inc., Waltham, Mass., and described at www.netegrity.com. Such single-logon methods avoid the need for repeated logons, but have severe limitations when used with state-less computing environment components.
U.S. Pat. No. 5,757,920 for "Logon Certification" and U.S. Pat. No. 5,999,711 for "Method and System for Providing Certificates Holding Authentication and Authorization Information for Users/Machines", both to Misra et al., describe logon certificates that are provided to support disconnected operation in distributed computing systems. Each logon certificate is a secure package holding credentials information sufficient to establish the identity and rights and privileges for a user or a machine in a domain that is not the user's/machine's home domain.
U.S. Pat. No. 5,241,594 to Kung for "One-Time Logon Means and Methods for Distributed Computing Systems" describes storing password files in all networked computers in a distributed system and, after a user logs on to a computer, forwarding authentication information to a second computer using a secure transport layer protocol if the user wishes to use services at the second computer. The second computer compares the user's authentication information it receives with the user's authentication information it stores, and if the information matches, the user is logged on to the second computer.
Other logon methods and systems are described in U.S. Pat. No. 5,655,077 to Jones et al. for "Method and System for Authenticating Access to Heterogeneous Computing Services"; U.S. Pat. No. 5,689,638 to Sadovsky for "Method for Providing Access to Independent Network Resources by Establishing Connection Using an Application Programming Interface Function Call Without Prompting the User for Authentication Data"; U.S. Pat. No. 5,768,504 to Kells et al. for "Method and Apparatus for a System Wide Logan [sic] in a Distributed Computing Environment"; U.S. Pat. No. 5,774,650 to Chapman et al. for "Control of Access to a Networked System"; U.S. Pat. No. 5,884,312 to Dustan et al. for "System and Method for Securely Accessing Information from Disparate Data Sources through a Network"; and U.S. Pat. No. 6,178,511 to Cohen et al. for "Coordinating User Target Logons in a Single Sign-On (SSO) Environment".
The problems with systems like that shown in
Such work flows and processes can be more complex than those typically associated with single-logon techniques. Moreover, many electronic records available to online inquiry are neither encrypted, nor hashed, nor digitally signed since to do so increases the processing time and resources needed for authorized users to access such information.
This invention solves the above-described and other problems suffered by computer and communication systems having restricted access, providing methods and systems for providing secure access to information in an on-line, networked environment in which traditional methods of verification, integrity, and authentication are generally inapplicable or ineffective. Important features of the invention involve an encrypted data element called a security context, which is securely built and accessible only by a trusted computing environment, thereby eliminating the risk of interception, modification, or unauthorized use.
In one aspect of the invention, a security context is built from a user's logon information and from system authorization information that define the user's access rights to protected on-line applications and electronic information. The security context is hashed and encrypted to protect the included logon and access information from theft and misuse. Following a successful logon that establishes a respective security context, the user may seek access to applications, transactions, and records without having to re-logon and without having to re-access a logon rules database. This does not preclude the user from requesting a new security context if necessitated by a change in either the user's role in a transaction or the type of transaction. A user's level of access can be controlled by a plurality of identifiers, such as the user's logon ID, the user's organization ID and sub-organization ID's, and the user's particular role or credentials within the organization. System resources protected in accordance with this invention are not limited to electronic records and computer-directed applications and transactions but also extend to secured equipment, such as facsimile machines and certified printers.
In another aspect of the invention, a method of enabling access to a resource of a processing system includes the steps of establishing a secure communication session between a user desiring access and a logon component of the processing system; verifying that logon information, provided by the user to the logon component during the secure communication session, matches stored information identifying the user to the processing system; generating a security context from the logon information and authorization information that is necessary for access to the resource; providing the security context to the user; and sending, by the user to the processing system, the security context and a request for access to the resource. The resource may be at least one of a processor, a program object, and a record of the processing system, and the logon component may provide a symmetric encryption key to the user in establishing the secure communication session. The user may digitally sign the request for access, the user's digital signature may be included with the request for access in a wrapper that is sent with the security context to the processing system, the user's digital signature may be checked by the processing system, and access to the resource may be granted only if the user's digital signature is authenticated.
The logon information may include a password and at least one of a user identifier, an organization identifier, a sub-organization identifier, a user location, a user role, and a user position. The logon information may be verified by checking for agreement between the stored information identifying the user to the processing system and the password and at least one of a user identifier, an organization identifier, a sub-organization identifier, a user location, a user role, and a user position provided by the user to the logon component.
The security context may include a plaintext header and an encrypted body, and the plaintext header may include a security context ID, a key handle, and an algorithm identifier and key size. The encrypted body may include at least one of a user identifier, an organization identifier, access information, an expiration time, public key information, symmetric key information, and a hash, and access to the resource may be denied if the expiration time differs from a selected time. The access information may specify at least one resource accessible by the user; the expiration time specifies a time after which the security context is invalid; and the hash is computed over the plaintext header and the encrypted body before encryption, and may be digitally signed by the logon component.
The method may further include the step of determining, by a stateless component of the processing system, based on the security context sent with the request for access by the user, whether access to the requested resource should be granted to the user. The request for access may be at least partially encrypted with a symmetric encryption key extracted from the security context. A hash value may be computed over the request for access and be included with the security context and the request for access sent by the user to the processing system, with the integrity of the request for access being checked based on the hash value, and access being granted only if the integrity of the hash value is verified. A request counter may be included in the request for access, and if access is granted, a response is sent to the user that includes a request counter, enabling the user to match the response to the request for access. A response can also be an acknowledgement of an action performed (e.g., creation of a "certified" printout of a record).
In another aspect of the invention, a processing system having resources, including various platforms such as processors, program objects, and records, that are selectively accessible to users includes a communication device through which a user desiring access to a resource communicates sends and receives information in a secure communication session with the processing system; an information database that stores information identifying users to the processing system and authorization information that identifies resources accessible to users and that is necessary for access to resources; and a logon component that communicates with the communication device and with the information database, wherein the logon component receives logon information provided by the user during the secure communication session, verifies the received logon information by matching against information identifying the user to the processing system that is retrieved from the information database, and generates a security context from the received logon information and authorization information. The logon component provides the security context to the user's communication device, and the user sends, to the processing system, the security context and a request for access to a resource. The processing system may further include a cryptographic accelerator, and the logon component may receive a symmetric encryption key from the cryptographic accelerator and provides the symmetric encryption key to the user's communication device.
Other aspects of the invention are described below.
The above needs are at least partially met through provision of the Systems And Methods For State-Less Authentication described in the following detailed description, particularly when studied in conjunction with the drawings, wherein:
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions and/or relative positioning of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of various embodiments of the present invention. Also, common but well-understood elements that are useful or necessary in a commercially feasible embodiment are often not depicted in order to facilitate a less obstructed view of these various embodiments of the present invention. It will further be appreciated that certain actions and/or steps may be described or depicted in a particular order of occurrence while those skilled in the art will understand that such specificity with respect to sequence is not actually required. It will also be understood that the terms and expressions used herein have the ordinary technical meaning as is accorded to such terms and expressions by persons skilled in the technical field as set forth above except where different specific meanings have otherwise been set forth herein.
It will be appreciated that Applicants' invention can be implemented utilizing commercially available computer systems and technology, and since the details of such are well known to those of skill in the art, they will not be described in this application.
In using secure transaction processing systems, even in a system such as that depicted in
The enrollment information is typically provided to an interface device such as an application server component 232 that communicates with a logon component 234 of the TCE 230. The logon component 234 or an equivalent device generates a password for the user and securely stores the password in a protected rules database 236. Since password generation and protection is often processing intensive, the TCE 230 may include a suitable cryptographic accelerator 238 or other special-purpose processor that implements the cryptographic algorithms used for generating and checking passwords and for other operations. The password is securely delivered to the user via the application server 232 and an approved courier 240. The approved courier 240 may be a traditional overnight service, such as Federal Express, that delivers the password in physical form, or an e-mail server or a facsimile machine that delivers the password electronically. The user receives the password (block 250) and must present the password to the TCE system 230 before access is granted. The TCE is so named because it includes the elements necessary for authenticated access to the transactions offered through the application server 232.
Many of the components for enrolling a user as depicted in
The logon component 234 examines all received enrollment information for compliance with rules and requirements maintained in the rules database 236, which must be protected storage to ensure the integrity of the identification and authorization information it maintains. Any received enrollment information that is not in compliance preferably causes a message to be displayed or other indication to be given to the information submitter to prompt submission of correct information. In general, the rules database 236 may be initialized with user authorization and attribute information in the form of data, flags, algorithms, business rules, etc. With this information, as will be discussed more thoroughly below, the system can provide varying levels of authorized access to system resources, depending on the particular organization or sub-organization the user represents and the role the user plays in accessing particular transactions and/or records.
As with conventional systems, the enrollment information obtained by the system administrator is passed to the logon component 234, which instead of merely storing a password in the rules database 236, first processes the password through a suitable protective method or device such as a hashing algorithm and stores the hashed password in the rules database such that it is associated, or linked, to the particular user by the user's logon ID and optionally by the user's organization ID. The logon component 234 then forwards the unhashed (plaintext) password to the user through any of the secure communication channels discussed above. After a user has been enrolled by the system 230 and has received a password, the user can access system applications, components, transactions, and records, but only after the user is authenticated as having authority to access the secured resources.
In these secret symmetric sessions, encrypted logon information is exchanged and passwords are validated as more thoroughly discussed below. Encryption helps to secure the integrity of the information exchanged between the User 310 and the Logon Component 334 during the logon process and to minimize the possibility that any of the logon information can be intercepted and used for unauthorized access to system resources. By generating and utilizing the encryption keys internally, the system 330 precludes external, unauthorized access to the keys.
The encryption key pair that has been most recently generated can be called the "current" key pair and is preferably allocated to all logon processing until the next key pair is generated. Key pairs advantageously are usable for respective limited periods of time, so that an earlier encryption key pair persists until it expires.
As an alternative to private/public encryption key pairs, the Logon Component 334 can use a known key exchange algorithm/protocol to generate a secret symmetric session encryption key. Exemplary algorithms for creating secret symmetric keys are the Diffie-Hellman algorithm and the Key Exchange algorithm of the NIST. Even so, it is currently preferred to use application server-side authentication employing an X.509 authentication certificate that enables establishment of a secure socket layer (SSL) session. As yet another alternative, user and server authentication certificates can be used to establish a two-way authenticated SSL session. The advantage of either SSL approach is its facilitation of the use of the Cryptographic Token and the Cryptographic Accelerator 338 that relieves both the user and the Application Server 332 processors from the burden of carrying out the cryptographic operations.
After a secret symmetric key is determined by the Logon Component 334, it is routed to the User 310 to establish a secure session, in which encrypted information can be exchanged by the User 310 and the Logon Component 334. The Logon Component 334 then requests logon information from the User 310. In response, the User 310 transmits its identity information and the local time ("Client Time") to the Logon Component 334.
The user's identity information preferably includes its logon ID, organization ID, password or shared secret (e.g., a personal identification number (PIN), a passphrase, biometric information (fingerprint, retina scan, voiceprint, etc.)), etc. The user's logon ID advantageously becomes the relative basis for accessing user-related authorization information in the Rules Database 336. The organization ID can include a hierarchy of IDs, each representing a sub-organization within the organization, such as a subsidiary or a department, to which the user may be associated. Additionally, the identity information can include user functional data, such as the user's role, position, or credentials in the organization. The password provided by the User 310 is typically hashed at the user's side of the exchange prior to transmission to the Logon Component 334 to provide an additional level of protection against unauthorized capture of the password during transmission. Further protection against unauthorized access to the user's password may be obtained by encrypting the password, e.g., according to RSA Laboratory's PKC Standards (PKCS) #5—Password-Based Cryptography Standard, using the secret symmetric key received from the Logon Component 334. The Client Time may also be provided during logon as an anti-spoof feature which will be described later in this description.
The Logon Component 334 decrypts the user-entered logon information if necessary, using the Application Server-side symmetric key and the Cryptographic Accelerator 338, and compares the logon information to the authorization information in the Rules Database 336, as linked by the entered user logon ID. The hash of the password entered by the User 310 is compared to the hashed password stored in the secured storage of the Rules Database 336, also as linked by, or related to, the entered user logon ID to determine that the two hashes match. If any of the identification and authentication information submitted by the User 310 is in error or fails to match the data or rules in the Rules Database 336, the User 310 is challenged by the Logon Component 334 to check and resubmit the User's information. After a predetermined number of failures, the logon session, and thus the User's access attempt, will be terminated. Such a limit helps prevent a brute force password attack. The User 310 may attempt to logon again, but several more sequential repeats of the logon failure, as determined by system security attributes in the Rules Database 336, will lock out the User 310 and will alert a system security officer. Alternatively, the Logon Component 334 may disable the User's logon ID in the Rules Database 336 until a system security officer can review the logon failures.
After the User's identification and password information have been presented and verified, the Logon Component 334 retrieves the User's authorization information from the Rules Database 336, as linked by the user's logon ID and conditioned on the user's organization ID(s) and role(s). Authorization information may be built at this point based on the user's organization ID(s) and role(s) as determined by any corresponding business rules in the Rules Database. The Logon Component 334 then creates a Security Context that conveys the user's identity and other relevant authorization information necessary to gain access to Application Server-based system resources, including online transactions and electronic records. This identity and authentication information is sufficient to qualify the User for the full range of activities needed to carry out those actions and accesses previously authorized for the User.
Referring now to
To eliminate any possibility of forgery or unauthorized alteration, the Security Context hash may be digitally signed by the Logon Component 334. The authentication certificate of the Logon Component may be made available to all system components.
The Security Context Body is then encrypted using the Logon Component-specified symmetric or the generated private key referenced by the respective Key Handle. The Security Context and the symmetric session encryption key contained therein are then forwarded to the User and retained for the period for which the Security Context is valid. In some instances, the Time-Offset and Expiration Time values may also be returned to the User, which allows the User to renew the Security Context prior to its expiration.
At this point, Security Context building, encryption, and placement are completed and communication between the User and the Logon Component are terminated. Transaction-level communication between the User, Client Application, and TCE are re-established.
Referring to
The Stateless Components 535 may be considered as existing at an "industry level" or at a "core level". Core-level components are reusable program objects that are industry-independent and thus will be understood as those components that are typically at the heart of any processing system. Thus, core-level components are used by all users of the TCE. The strongest security enforcement is found at the core level where access restrictions can be enforced broadly. Industry-level components are also reusable program objects but are industry-dependent. Thus, industry-level components are used by only a subset of all users of the TCE, i.e., the subset of users that can be categorized as the respective "industry". It will be appreciated that this description of different levels is merely for organizational convenience and that one or more levels may be employed.
It will be understood that the operation of the TCE 530 is effectively transparent to the User 510, who simply logs onto the system and operates as the User would in an otherwise conventional distributed processing system. An important difference is that a permanent session does not have to be established between each User 510 and Application Server-side components in the TCE 530. Application Server-side components can therefore be stateless since all the information needed to authenticate a User's request is communicated in the Security Context that is included in the User's request. After a Stateless System Component 535 finishes a task, it is free to service another User's request.
Referring again to
A Bypass Flag(s) field indicates which, if any, security features are disabled. This reduces computation overhead when the Security Context is used among Stateless System Components 535 in an otherwise protected and trusted environment, as discussed more thoroughly below. Although illustrated as a single field, a Bypass Flag may be associated with each security feature to indicate whether or not the feature is used.
A Time-Offset field is used by the Logon Component 334 and Stateless System Components 535 to adjust for discrepancies between TCE system (current) time and Client Time, which is the time at the User's computer or browser (see
An Expiration Time field identifies the time of expiration of the Security Context, placing an upper limit on the life of the Security Context. This is enforced by the Stateless System Components 535 and can be used by Users to renew their Security Contexts. An Expiration Time is also associated with every Security Context encryption key. Exceeding the Expiration-Time value forces the Logon Component 334 to create a new Security Context encryption key. In this way, the number of Security Contexts that are protected by a given key and uses thereof can be limited. The Security Context encryption keys are deleted on the Application Server-side after the Expiration-Time value is exceeded, and thus subsequent attempts to access transactions or records using Security Contexts with outdated encryption keys fail. Either symmetric or asymmetric encryption may be employed.
The Logon Component 334 may also establish a maximum count for the number of times a particular Security Context encryption key is used. When the count in a Request Counter field (see
The User Public Key Algorithm field may contain an algorithm ID, key, and/or Authentication Certificate. The public key pair may be generated by the Logon Component 334 or the Client Application, or created in conjunction with the issuance of a user's X.509 authentication certificate and public-key pair delivered in a Cryptographic Token. The private key is held at the User's location, possibly in a hardware Token. The public key is passed to the Logon Component 334 during symmetric session key negotiations or is passed in the user's X.509 certificate. To reduce processing overhead, the public key information may be extracted from the X.509 certificate and placed directly in the Security Context.
Referring again to
All Stateless System Components 535 that may be asked to perform some action or to access desired information in response to a User request must be given access to the User's Security Context to determine whether the requested action or access is authorized. Since the Security Context is encrypted, the Stateless System Components 535 are provided with the right to use the cryptographic key identified in the Plaintext Header to read the contents of a particular Security Context, including the Authorization Information, in conjunction with the set of cryptographic services performed by the Cryptographic Accelerator 538. In addition to implementing controls to limit User access to protected Components, this invention may also be applied to automatically authenticate action and access requests between Stateless System Components 535.
Following successful creation of a Security Context for a given user logon session, the Security Context can be effectively applied in several ways to control securely and efficiently user access to protected program objects and records. As illustrated by
It will be appreciated that the User Request or Submission depicted in
Upon receipt of a Security Context/User Request, a Stateless System Component 535 directs the decryption of the Security Context. The Stateless System Component 535 first uses the Plaintext Header Key Handle and Algorithm Identifier information to identify the corresponding cached decryption key to the Cryptographic Accelerator 538. A number of active symmetric and asymmetric encryption and decryption keys are held in protected storage by the Cryptographic Accelerator 538, and each is referenced by a unique handle contained in a Security Context header as described above. The Stateless System Component 535 then enables the Cryptographic Accelerator 538 to decrypt the Security Context Body and User Request, which make the User's identification and access authorization information and the request contents available to the Component.
The Stateless System Component 535 verifies the integrity of the received Security Context and User Request by verifying the respective hashes and/or the digital signature, if used. The Stateless System Component 535 compares the roles, credentials, and authorization information from the decrypted Security Context Body with the User Request. If there is a mismatch between the authorization information and the Request, the access attempt fails and the User 510 is so notified, and control is passed back to the User 510 either to submit another Request or to terminate the session. Similarly, if the time of submission is outside the Expiration-Time window for the Security Context, then the access attempt fails. If insufficient information exists in the Security Context authorization information field, the Stateless System Component 535 may access the Rules Database 536 for additional information. If insufficient information still exists after accessing the Rules Database 536, the access request fails, and the User 510 is so notified. If the access verification process has been successful, then the Stateless System Components 535 are permitted to proceed with fulfilling the user request, with a response ultimately being directed back to the User 510.
As illustrated by
The Request Counter field is typically initialized at zero at the creation of the Security Context and is incremented each time a User Request with this particular Security Context is directed to the Stateless System Components 535. In this way, use of the Security Context can be limited, with the User being denied access should the Request Counter exceed a predetermined maximum. It will be appreciated that decrementing Request Counters can also be used. Additionally, the Request Counter may be used to match Requests with System Component responses when responses are returned asynchronously (out of chronological order). Thus, a request counter is included in the request for access, and if access is granted, a response is sent to the user that includes the a request counter, which the user uses to match the response, which may be an acknowledgement of an action performed (e.g., creation of a "certified" printout of a record), to the request. Finally, the Request Counter can prevent "replay" attacks, in which a hacker intercepts a User Request or Component Response and falsely presents the Request for access to a protected transaction or record or replays the Response to create network and system congestion. The system 530 and client application 520 both recognize when the Request Counter in the Security Context/User Request data stream is out of synchronization with previous Requests and reject the false Request. Alternatively, Client Time (
In another embodiment, the User Request portion of the secured Security Context/User Request stream depicted in
In another embodiment, all or part of a User Request may be hashed prior to being forwarded to the Stateless System Component 535, with the hash value being appended to the User Request. The Stateless System Component 535 would then hash the received User Request and compare its result with the hash value appended to the User Request. If the two hash values match, the system can be reasonably assured that the User Request has not been modified. If the two hash values do not match, the User-side application can be instructed to re-send the Security Context/User Request/Hash data stream, or a message can be sent to the User advising that receipt of a corrupt Request resulted in failure prior to the request authorization process.
In yet another embodiment, a digital signature can be applied to all or part of the Security Context/User Request data, with the digital signature being verified upon receipt by the Stateless System Components 535. Upon verification or non-verification, the Stateless System Components 535 proceed as described above in connection with Request validation. Both the hashing and digital signature features help prevent middleman and substitution attacks on the access authorization process.
In yet another embodiment of the invention, encryption and hashing of the User Request are combined to provide a secure, non-forgeable session for the authorized access of transactions and records.
It should be understood that a User does not have access either to the Security Context encryption key or to the contents of the Security Context. Only the Logon Component and Stateless System Components have such access. Use of a digital signature by the Logon Component prevents modification by any component, enabling the Security Context's content to be trusted. The User Request encryption key, Time Offset, and other relevant information needed by the User are passed to the User/Client Application during the secure Security Context setup session. It will be appreciated that both trusted and untrusted Stateless System Components can be used by layering the methods described here, increasing bit overhead as needed to achieve an appropriate level of protection.
Application of the methods described above is illustrated by
In block 802, a system administrator is instructed by an authorized source to enroll a user, whose identification and authorization information is entered into a system enrollment database. The user is assigned a user ID and preferably an organization ID that uniquely identifies the user to the system, although it will be understood that other means of uniquely identifying users may be employed.
Block 804 indicates that three password methods may be supported: initialize (requiring the system administrator's password); check (requiring the logon component's password); and change (requiring a user's current password). During enrollment, a default password may be created and assigned to the user. The hash of the default password is associated with the user's unique identity and saved in protected storage. The plaintext password is made available to the system administrator, who arranges for its delivery to the user, preferably using an out-of-band means, such as an approved courier. The logon component facilitates the user's changing its default password to one that is more memorable. A new password can be issued if the user forgets its password or believes its password may have been compromised or from time to time
In block 806, a private key is used by the system's logon component to protect security contexts. A new PKC pair is generated at suitable intervals, which may vary by application or industry. The most recently generated key pair can be called the current key pair, and key pairs may conveniently be generated by any suitable hardware cryptographic accelerator. The handles of the private key and public key of the current key pair are made available to the logon component. The private key is accessible only to the logon component. Prior (non-current) key pairs persist until their respective expiration times are reached. This overlap is chosen to be sufficiently long as to minimize the need for Users to have to request new Security Contexts. The logon component uses only the current key pair.
In block 808, the public key handle is shared with trusted stateless system components that, as trusted components, must be implemented in a protected operating environment. Access to a trusted system component is granted by the logon component's sharing the current public key handle and the address of the cryptographic accelerator with the component. Access by any other component is blocked, for example by a software or hardware firewall. Any such components require a Security Context to access system resources.
In block 810, the first occurrence of a user's needing access to system resources (components) requires the user, through its client application, to initiate a communications session with the logon component. An SSL session is preferably invoked.
In block 812, if an SSL encrypted session is not used, the user's client application engages in an exchange with the logon component that results in a symmetric-session encryption key existing at both the client application and the logon component. This symmetric-session encryption key is the basis of subsequent secure communications between the user and the system and authentication with all trusted stateless system components. The symmetric-session encryption key may be used to encrypt user service requests.
In block 814, the user presents its credentials to the logon component, which asks the user to enter its unique identifying information and password. At this point, the user may be given an opportunity to change its password, either its default password generated at enrollment or its current password. System security policy typically dictates how often a user must change its password.
In the following description, the logon information is encrypted using a session-symmetric key, although as noted above an SSL session could be used. The user's client application forwards the user-entered information to the logon component using a predefined self parsing data structure such as the following, in which { } indicate an encrypted value, subscript identifies a key, and [ ] indicate plaintext:
To change a user's password, the client application forwards the user-entered information using a data structure such as the following:
In block 816, the logon component decrypts the Password(s) and Client Time using the symmetric-session key and computes a Delta Time value, which is the difference between the Client Time and the system time of the core server. The user's Password is then hashed according to an algorithm such as SHA-1 and compared to a hash value stored in the system database. If the hashes match, the user's Password is validated, and if a change of Password is requested, the logon component initiates the Password change procedure. If Password validation fails, the user may be given one or more chances to submit a correct Password, as specified by system security policy, before being locked out of the system.
In block 818, after successful user/client logon, the logon component builds and returns to the user/client a Security Context (SC) that preferably includes the following elements:
In block 820, the user/client application may submit requests to trusted stateless system components using the SC returned to the user/client by the logon component. The client does so by appending a request to the SC. Two examples of SC-request combinations follow:
In block 822, the SC and request are verified by any trusted stateless system component by using the stored key referenced by Handle.sub.Public-current to decrypt the body, then extracting and using the symmetric-session key to decrypt the encrypted portion of the Request, validating the Request by at least checking that system time=Client Time.+−.Delta Time, and further verifying the request by validating a hash and/or client digital signature if used
In block 824, if the SC and Request are successfully validated, then the stateless system component uses the content of the SC and Request to perform the requested actions. In this way, the stateless system component may act as a trusted proxy for the user/client. The result of the request, if fulfilled, is returned to the user/client application. If desired, the result may be encrypted using the symmetric-session key.
It will be understood that these methods and systems are effectively transparent to a user, who simply logs on to the system and operates as the user would in a conventional distributed system. An important difference is that a permanent session does not have to be established between the user/client application and server-side components, which can be stateless since all the information needed to authenticate a user's request is communicated in an non-forgeable security context. After a stateless system component finishes its task, it is free to service another user request. Additional request capacity may be obtained by simply adding application servers and/or instantiating stateless system components (program objects). These additions will also be totally transparent to client applications.
Although preferred embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that changes may be made in these embodiments without departing from the principle and spirit of the invention, the scope of which is defined in the appended claims and their equivalents.
1. A method of accessing any of a plurality of resources wherein at least some of the resources do not share a common processing platform, the method comprising:
- establishing a secure communication session between a user computing device and a logon component, wherein the secure communication session comprises a temporary, interactive information exchange that is set up and then torn down;
- verifying logon information provided by the user computing device to the logon component using the secure communication session and responsively generating a security context to be employed by the user computing device that is: unique to a user of the user computing device; necessary to access any of the plurality of resources without requiring any follow-on authorization communications between the accessed resource and the logon component.
2. The method of claim 1 wherein verifying the logon information comprises comparing the logon information to previously stored information that identifies the user.
3. The method of claim 1 wherein a security context that is unique to the user comprises, at least in part, a unique identifier as corresponds to the user.
4. The method of claim 1 wherein the security context comprises a stateless security context.
5. The method of claim 1 wherein generating a security context to be employed by the user computing device comprises generating a security context that will support contemporaneously accessing at least two of the plurality of resources.
6. The method of claim 1 wherein generating a security context comprises generating a security context that automatically preserves access limitations specific to the user as corresponds to varying ones of the plurality of resources such that the user's degree of access to a given accessed resource can vary notwithstanding a common use of the security context.
7. The method of claim 1 wherein generating a security context comprises generating a time-limited security context.
8. The method of claim 7 wherein generating a time-limited security context comprises including a time stamp in the security context.
9. An apparatus comprising:
- at least one trusted computing environment component configured to facilitate:
- establishing a secure communication session between a user computing device and a logon component, wherein the secure communication session comprises a temporary, interactive information exchange that is set up and then torn down;
- verifying logon information provided by the user computing device to the logon component using the secure communication session and responsively generating a security context that is: unique to a user of the user computing device; necessary to access any of the plurality of resources without requiring any follow-on authorization communications between the accessed resource and the logon component.
10. The apparatus of claim 9 wherein the security context comprises, at least in part, a unique identifier as corresponds to the user.
11. The apparatus of claim 9 wherein the security context comprises a stateless security context.
12. The apparatus of claim 9 wherein the security context is operable to support contemporaneously accessing at least two of the plurality of resources.
13. The apparatus of claim 9 wherein the security context automatically preserves access limitations specific to the user as corresponds to varying ones of the plurality of resources such that the user's degree of access to a given accessed resource can permissibly vary notwithstanding a common use of the security context.
14. The apparatus of claim 9 wherein the security context comprises a time-limited security context.
15. The apparatus of claim 14 wherein the time-limited security context includes a time stamp.
16. A method to facilitate accessing protected on-line resources via corresponding secured transactions, comprising:
- at a user computing device:
- presenting, to other than the on-line resources, at least a logon identifier;
- responsively receiving a corresponding stateless security context that is unique to the user,
- wherein no request history is retained at the user computing device and authentication using the stateless security context is independent of a particular state, application, transaction, or routine being invoked;
- using the stateless security context to access a plurality of differing on-line resources via a plurality of corresponding secured transactions.
17. The method of claim 16 further wherein using the stateless security context to access a plurality of differing on-line resources via a plurality of corresponding secured transactions comprises using the stateless security context to at least partially contemporaneously access a plurality of differing on-line resources via a plurality of corresponding secured transactions.
18. The method of claim 16 wherein presenting, to other than the on-line resources, at least a logon identifier comprises presenting the logon identifier to a logon component as comprises a part of a trusted computing environment.
19. The method of claim 18 wherein using the stateless security context to access a plurality of differing on-line resources via a plurality of corresponding secured transactions comprises accessing any of the plurality of resources without conducting any follow-on authorization communications between the accessed on-line resources and the logon component.
Referenced Cited
U.S. Patent Documents
|August 31, 1993
|May 10, 1994
|Scott et al.
|December 12, 1995
|January 2, 1996
|December 31, 1996
|Krajewski, Jr. et al.
|March 25, 1997
|Bisbee et al.
|August 5, 1997
|Jones et al.
|November 4, 1997
|Dare et al.
|November 18, 1997
|February 17, 1998
|Swift et al.
|May 5, 1998
|Bisbee et al.
|May 26, 1998
|Misra et al.
|June 16, 1998
|Kells et al.
|June 30, 1998
|Chapman et al.
|September 1, 1998
|Karaev et al.
|January 26, 1999
|Kitain et al.
|March 16, 1999
|Dustan et al.
|August 10, 1999
|August 31, 1999
|December 7, 1999
|Misra et al.
|November 14, 2000
|January 23, 2001
|Cohen et al.
|February 20, 2001
|May 22, 2001
|Bisbee et al.
|August 14, 2001
|Kao et al.
|October 23, 2001
|November 6, 2001
|Serbinis et al.
|December 4, 2001
|Boroditsky et al.
|December 18, 2001
|Boroditsky et al.
|January 8, 2002
|Ault et al.
|April 2, 2002
|Bisbee et al.
|April 23, 2002
|Ault et al.
|June 4, 2002
|Brezak, Jr. et al.
|July 16, 2002
|July 30, 2002
|Brezak, Jr. et al.
|November 19, 2002
|Wall et al.
|June 17, 2003
|April 12, 2005
|Chinta et al.
|March 28, 2006
|Bisbee et al.
|February 2, 2010
|Bisbee et al.
Other references
- SAM, Security Aspects of Mobile IP, 2001, Google, 9 pages.
- Suan-Suan Chew et al., IAuth: An authentication system for Internet applications, Aug. 13-15, 1997, IEEE, 654-659.
- Fox et al., "Cooperative security": a model for the new enterprise, Jun. 17-19, 1998, IEEE, 314-319.
- Bellovin, Steven M. "Probable Plaintext Cryptanalysis of the IP Security Protocols", IEEE (1997), pp. 52-59.
- Herda, S. "Non-repudiation: Constituting evidence and proof in Digital Cooperation", Computer Standards and Interfaces, vol. 17, No. 1 (Jan. 1995), pp. 69-70.
- Kormann, David P., et al. "Risks of the Passport Single Signon Protocol", IEEE Computer Networks, vol. 33 (2000), pp. 51-58.
- Lowry, J. "Location-independent Information Object Security", Proceedings of the Symposium on Network and Distributed System Security, San Diego, CA (Feb. 17, 1995), pp. 54-62.
- Netegrity, Inc. [online] [retrieved on Apr. 11, 2001] Retrieved from the Internet: <http://www.netegrity.com> All Pages.
Patent History
Type: Grant
Filed: Jan 21, 2010
Date of Patent: Nov 1, 2011
Patent Publication Number: 20100122326
Assignee: Teigel Processing AB, L.L.C. (Dover, DE)
Inventors: Stephen F. Bisbee (Baltimore, MD), Jack J. Moskowitz (Ellicott City, MD), Keith F. Becker (Baltimore, MD), Ellis K. Peterson (Arnold, MD), Gordon W. Twaddell (Millersville, MD)
Primary Examiner: Jean B Fleurantin
Attorney: Fitch, Even, Tabin & Flannery
Application Number: 12/691,547
International Classification: G06F 7/00 (20060101); G06F 17/30 (20060101);


text:
toe(redirected from -toed)
Also found in: Dictionary, Thesaurus, Encyclopedia.
a digit of the foot.
claw toe a toe deformity seen in many patients with rheumatoid arthritis, consisting of dorsal subluxation of toes 2 through 5; the metatarsal heads bear weight and become painful during walking so that the patient has a shuffling gait.
hammer toe deformity of a toe in which the proximal phalanx is extended and the second and distal phalanges are flexed, causing a clawlike appearance; it most often affects the second toe.
Morton's toe Morton's neuralgia.
pigeon toe a permanent toeing-in position of the feet; severe cases are considered a form of clubfoot (talipes).
webbed t's syndactyly of the toes abnormally joined by strands of tissue at their base.
toe(tō), [TA]
One of the digits of the feet.
Synonym(s): digitus pedis [TA], digits of foot ☆
[A.S. ta]
toe(to) a digit of the foot.
claw toe dorsal subluxation of toes 2 through 5, the metatarsal heads bearing weight and becoming painful when walking, resulting in a shuffling gait; occurring in rheumatoid arthritis.
hammer toe deformity of a toe, most often the second, in which the proximal phalanx is extended and the second and distal phalanges are flexed, giving a clawlike appearance.
Morton's toe see under neuralgia.
pigeon toe permanent toeing-in position of the feet.
tennis toe painful great toe associated with subungual hematoma; so called because it develops usually after vigorous tennis playing.
webbed toes syndactyly of the toes.
a. One of the digits of a vertebrate foot.
b. The forepart of a foot or hoof.
c. The terminal segment of an invertebrate's limb.
To stand, walk, move, or be formed with the toes pointed in a specified direction: He toes out.
any one of the digits of the feet.
TOEAbbreviation for:
tender on examination
transoesophageal echocardiography
toeSee Claw toe, Curly toe, Hammer toe, Mallet toe, Overlapping toe, Pheasant hunter's toe, Pigeon toe, Sausage toe, Tennis toe, Turf toe, Underlapping toe.
toe(tō) [TA]
One of the digits of the feet.
[A.S. ta]
toe(tō) [TA]
1. Rounded third of the working end of a curette.
2. One of the digits of the feet.
[A.S. ta]
a digit of the foot.
toe abscess
see foot abscess.
toe crack
see sandcrack.
curled toe
see curled toe paralysis.
kicked-up toe
a common injury in dogs, particularly racing Greyhounds, in which the deep flexor tendon is ruptured causing the affected claw to be elevated above others on the foot. Called also knocked-up toe.
toe out
the limb is rotated slightly so that the toe points a little outward.
toe picking
a vice of very young chickens that are hungry because feed supplies are inaccessible or inadequate. They pick each other's toes and start an outbreak of cannibalism.
sand toe
see sand toe.
seedy toe
see seedy toe.
splayed toe
see splayed digits.
sprung toe
a problem of racing Greyhounds characterized by dislocation of the proximal interphalangeal joint through rupture of the medial collateral ligament. The toe is displaced laterally, usually overriding the next toe.
Patient discussion about toe
Q. I have a pain in my big toe, what is it? I keep on having shooting pains from my big toe, especially at night. What could it be from?
A. Go see your Doctor as he can determine the joint's condition with an X-ray. Arthritis (such as arthritis caused by gout) is among the most common reasons for toe pain.
Q. how to treat nurve pain in my toes the top of my toes fell like they are aburning
A. Neuropathy can be treated by nutrition and several form of alternative medicine, like acupuncture.
check out this article on Peripheral Neuropathy from the Gale Encyclopedia of Alternative Medicine to learn more:
check out this article on Peripheral Neuropathy from the Gale Encyclopedia of Alternative Medicine to learn more:
Q. my guy friend has a very sick looking toe nail, what should he do? its really thick and has ridges, its also dark yellow and it looks to me has thick toe jam too... ugh, he needs your help please!
A. It sounds like Toenail fungus. Symptoms of toenail fungus, which can be caused by several types of fungi, include swelling, yellowing, thickening or crumbling of the nail, streaks or spots down the side of the nail, and even complete loss of the nail. Toenail color can vary from brown or yellow to white with this condition. I suggest your friend goes to see a foot doctor. The doctor might remove as much of the nail as possible by trimming, filing or dissolving it. Medicated nail polish might be prescribed for a localized infection, but a serious infection will likely be treated with a prescription oral antifungal medication. Only in severe cases will surgical removal of the nail be recommended.More discussions about toe

subset: commoncrawl


text:
What is Gather?
It is a place where you can explore your interests and passions with like-minded individuals. Wegather. Now more than ever, with the advent of social media, each and every one of us has a voice. In the past, the ability to communicate with multitudes of people took an extreme effort of will involving pens, paper, stamps and envelopes. The more ambitious and wealthy individuals could make themselves heard through mediums such as radio or television.
Today, being heard is as simple as logging on to Gather. Our website allows you to chat with potentially millions of different cultures, all over the world. Anyone who has access to the internet can communicate through this platform. The world has gotten smaller and this makes the individual's voice that much louder!
Having the ability to share our thoughts, beliefs, ideas and opinions through social media is only one among a myriad of world changing benefits offered by these platforms. Another benefit which is related, but slightly different, is that people from all the world's cultures can now communicate directly. Wegather. Throughout history, the world has been plagued with misunderstanding and misinformation.
We have often been led to believe that other cultures are so vastly different from our own that establishing any common ground is next to impossible. Now that it is possible to converse with friends all over the world, it should also be possible to dispel a vast majority of cultural misconceptions. We are all people in this world, and we can get to know one another.
Social media, above anything else, offers us a platform to get to know one another. An open forum acting as a safe space for the free and open exchange of ideas and information. Conversation is possibly one of the most enlightening activities in which to engage. Using social media to converse, freely and openly, with individuals anywhere in the world is one of the best ways to foster a sense of understanding across cultural boundaries. In addition to this, conversation also has a host of other benefits. According to Cecile Andrews, talking to others promotes health, happiness and longevity. Essentially, the effective use of social media to connect and communicate is not only beneficial in bringing others together, it offers personal benefits as well.
Use Gather to Meet New Friends
Conversation comes easily enough for most people, but there are a few things to keep in mind in order to make the process more effective:
- Ask good questions: good conversation requires back and forth communication. In order to keep things interesting, make sure to ask good, thought provoking questions. As an example, "So, what's new?" is a much better opening question than "How've you been?"
- Share the floor: In a conversation, listening is just as important as talking. So, whenever you are engaged in a conversation, make sure the other party gets their chance to speak. If you find that you are the only one doing the talking, take a step back, ask the other person what they think and give them a chance to respond.
- Don't be combative: Everyone disagrees from time to time, but it's important not to turn disagreements into fights. If someone offer a point of view that differs from your own, it's okay to offer your point of view, but try to do so in a positive and non-confrontational way.
- Stay positive with Gather: Sometimes it's easy to get swept away by negativity. Negative conversation includes complaining, insults, and threats. Stay away from these things to keep a conversation healthy and engaging. Wegather. Sometimes, it's impossible to avoid being negative, in these cases try using humor to decrease the intensity of your words.
- Social media gives everyone a voice, and gives us the ability to have healthy, stimulating conversations with people all over the world. If we engage others with sensitivity and courtesy, the conversations we have using social media is not only capable of bringing the world closer together, but helping us live healthier happier lives!
stranger chat
chat with random people
talk to people
gather app
chat ave
chat avenue
Talk to people online
talk to people
talk to random people online
talking online
chat rooms
how to talk to people online
chat online with people
free online chat
WeGather app
we gather app
wegather app
we gather
wegather online
we gather online
we gather.online
we gather community


text:
PONTIAC GRAND AM 1990-2005 performance parts will substantially increase the performance of your engine. Your engine will benefit from our wide variety of chips, performance parts, intakes and spark plugs for your PONTIAC GRAND AM 1990-2005. Adding these PONTIAC GRAND AM 1990-2005 performance parts to your vehicle will make your engine feel more powerful and responsive. It is not uncommon for your vehicle to gain 30 – 50 horsepower, increased throttle response, and increased efficiency. The performance parts listed here are specially designed for your vehicle and all are custom to your PONTIAC GRAND AM 1990-2005.
Copyright © 2019 AutomotivePerformanceParts


text:
Program Manager
From MeritBadgeDotOrg
|Serving as Program Manager can apply towards Positions of Responsibility requirements for Star, Life, and Eagle.
|Program Manager
A Program Manager is a special program youth leader in the Varsity Scout team. Plans and is primary leader for practice sessions and event activities within the team.
Position description
A Program Manager is an appointed leader of program activities in his team. He works with an adult Program Advisor to plan and perform primary leadership for team practice sessions and events in one of the five fields of emphasis: Advancement, high-adventure/sports, personal development, service, and special programs and events. He usually serves a 6- or 12-month term.
The original aims and purposes of Scouting outlined by Lord Baden Powell were to teach boys and young men spirituality, self-reliance, service, leadership skills, emergency preparedness, and conservation of natural resources. The program manager's greatest challenge is to see that every Varsity Scout is involved and each field of emphasis.
Reports to
Five fields of emphasis program managers
- Advancement Program Manager
- High-Adventure/Sports Program Manager
- Personal Development Program Manager
- Service Program Manager
- Special Programs and Events Program Manager
The Program Manager is a youth special program leader in its unit. Other youth program leaders are:
Program helps
Annual planning
- Varsity Annual Planner (25K PDF) Modified, Utah National Parks Council, Provo District (2001).
- Annual Varsity Scout Team Planning Chart (25K PDF) BSA 2003.
Event and ultimate adventure planning
- Varsity Scout Team Activity Planning Worksheet (25K PDF) BSA 2003.
- Varsity Scout Team Activity Planning Worksheet (33K PDF) Modified, Team 336 Omaha, NE (6/06).
- Varsity Scout Team Activity Planning Worksheet (8K PDF) Modified, Utah National Parks Council, Provo District (2001).
- Varsity Scout Sample Trip Plan (29K PDF) BSA 2003.
- Ultimate Adventure Planning Checklist (33K PDF) BSA 2003.
See also
|Varsity Scout portal
- Positions of Responsibility
- Team
- Denali Award
- Venture Patrol
- Venture Patrol Leader
- Star Rank, Life Rank, and Eagle Scout Rank
Team Positions of Responsibility and Adult Advisers
|Team Leadership:
| Captain • Cocaptain • Team Secretary • Squad Leader • Quartermaster • Chaplain Aide •
Librarian • Instructor • Den Chief • Order of the Arrow Team Representative
|Program Managers:
|Advancement • High-Adventure/Sports • Personal Development • Service • Special Programs and Events
|Other team leadership:
|Historian • Bugler
|Team Coach • Assistant Team Coach(es) • Committee Secretary • Committee Treasurer
|Program Advisers:
|Advancement • High-Adventure/Sports • Personal Development • Service • Special Programs and Events


text:
Killer Thrillers (HEEhee!)
[howling wind and dog together]
[plus a sprinkling of light rattling chains]
Darkness falls across the land...
Prince Humperdink: SKIP to the end!
And Grizzly ghouls from EVERY tomb...
Or maybe a Canadian Black Bear, eh?
Are closing in...to seal your DOOM.
And though you fight to stay alive...
"Ha. Ha. Ha. Ha. I'm missin'myarm, and whereismyface?"
Your body starts to SHIVER.
(Or maybe that's Orlando Bloom. Hm? LADIES?)
For no MERE MORTAL can resist...
... David Caruso riding a unicorn under a double rainbow!
The EVIL...
(Oh. Or that)
Thanks to Melinda M., Sarah C., Natasha, Nell H., John M., Rebecca J., Carrie, Robin L., Wolfie, and P. Humperdink for saving us from having to find a cake for "y'alls neighborhood."


text:
2008 :: Pearce Cycles Downhill Series, Rhyd-y-Felin, Bala ...
Dry, dusty high speed racing from one of the racers favourite UK tracks. Pearce Round 4 was a superb chance to ride and a warm up for the National Champs to be held here later this year.
You are viewing the thumbnail index - click a pic to enlarge.
All images in this gallery are © [ gravity-slaves ] and may not be reproduced without permission.


text:
Each Symposium is unique and you are encouraged to visit the specific symposia page for the meeting you plan to attend to learn more.
The following opportunities are available for all Special Symposia:
The American Society for Biochemistry and Molecular Biology (ASBMB) presents "Best Presentation" and/or "Best Poster" awards at each Symposium. An abstract must be submitted to compete for awards. Awardees are selected and acknowledged during the meeting and presented with their award and certificate. Please visit the each meet for further information on the number of awards available and deadline requirements.
Travel awards are available through the FASEB MARC office to support and encourage the participation of minority scientists attending the symposim. The travel awards are available for faculty scientists, post doctorates and advanced graduate students from underrepresented groups in teh biomedical and behavioral sciences. These groups include but are not limited to: African Americans, Alaskan Natives, Hispanic Americans, American Indians/ Native Americans who maintain tribal affiliation of community attachement, and Natives of the USA Pacific Islands (Guam, Hawaii and American Samoa only).
TYPES OF AWARDS: There are two types of travel awards available (designated with the MARC logo). 1. Faculty/ Mentors and Student Travel Awards 2. Poster/ Platform (Oral) Presenter Travel Awards.
Click to Learn More and apply for an award.
11200 Rockville Pike, Suite 302, Rockville, MD 20852-3110Phone: (240) 283-6600 • Contact us Privacy Policy© Copyright 2019 American Society for Biochemistry and Molecular Biology


text:
UPDATE: The New York Times has a story about this trend. You can read it by clicking here.
Democrats are taking advantage of Tom Tancredo's popularity by pointing out to 4th Congressional District voters that a member of Tancredo's own party is on the ballot in that race.
The efforts to link Doug Aden of the American Constitution Party to Tancredo, the ACP's gubernatorial nominee, and a no-frills, less-government agenda no doubt annoys Republican Cory Gardner but it delights supporters of Democrat Betsy Markey.


text:
The Truth about Insulin and Type 2 Diabetes
Most people associate taking insulin with type 1 diabetes. However, some people with type 2 diabetes also need to take insulin. We talked with Andrea Penney, RN, CDE, Joslin Diabetes Center, to find out the truth about insulin and type 2 diabetes.
Why would someone with type 2 diabetes who has been controlling their diabetes with diet and exercise need to start taking insulin?
There are several reasons why someone would require insulin, even if they hadn't needed it before.
- Temporary insulin usage– Some people need to take insulin for a short amount of time, because of things like pregnancy, surgery, broken bones, cancer, or steroidal medicines (like Prednisone).
- Permanent insulin usage - Sometimes the pancreas becomes unable to produce enough insulin. This happens frequently with aging. People can also become insulin resistant due to weight gain or chronic emotional or physical stress. Simply put, pills can no longer control diabetes.
So, it's not usually "bad" behavior that would cause someone to start insulin?
Correct. However, non adherence to diet and exercise might result in high blood glucose levels that only insulin can control.
Is insulin dosage different for someone who has type 2 rather than type 1?
The doses will vary; either type may require very little or a lot of medication. It depends on weight, eating habits, exercise levels, existence of other illnesses and level of insulin resistance.
Can someone start taking insulin and then not need to take it anymore?
Absolutely! But only for those with type 2 diabetes. Often weight reduction and /or exercise can allow insulin to be stopped. Also, if any of the temporary situations listed above resolve, insulin might be stopped.
Page last updated: September 18, 2019


text:
About : bit.ly/2n8PWVh
The virtual world of AVAKIN LIFE: an amazing 3D experience where you can meet people, chat & dress up! Decorate and design your home and visit astonishing, paradise locations!
Simulation and role playing game with countless possibilities!
It's an exciting and vibrant virtual world! A second life where you can become the person you always wanted to be.
Create your avatar and join millions of other people who already downloaded this fun role playing game!
Dress up your avatar, design and decorate your home. Buy new clothes, discover new, amazing brands and create your own perfect outfit. Be a fashion star and the centre of attention. Go on dates and parties in paradise locations. Show off your dream home. Message new friends. Explore this ever-growing virtual reality 3D world of AVAKIN LIFE now!
Add Unlimited AvaCoins.
Add Unlimited Diamonds.
bit.ly/2n8PWVh Avakin Life Hack Latest Version (With New Version).
bit.ly/2n8PWVh Avakin Life Cheat Tool Undetectable, Safe and Effective (100% Safe).
Protected with Anti Ban Security and User - friendly Layout.
No Need ROOT or JAILBREAK Mobile Devices.
No Download Needed apk. So simple but Worked.
Processing, please wait...
Almost done!
We are sorry, the auto verification process has been limit (200). Please do it manually to get AvaCoins and Diamonds
Input your username or E-mail.
Input amount of AvaCoins & Diamonds resources with what you want (MAX: 1.000.000).
Wait for a second, the server is processing your request. (we also showing process detail).
If the generator is working, it will display human verification to avoid Spam or Robot.
and If the generator not showing human verification, so reload the current page and start from first step again.
After all is done, go back in the generator page and you'll see a status.
Let's open the game in your devices and look, your resources is there and ready to use.
Similiar Post
âś… 100% Working Tools k32.win/avakin Avakin Life
âś… Easy Hack Avakin Life From avakin-life-hack.online
⚡ How to get AvaCoins & Diamonds from avakinlife.rootcheats.com
âś… Free 100% avakincheats.club Online Generator Diamonds AvaCoins
✔ Easy way to hack Avakin Life From avakin.wiredhacks.com for AvaCoins and Diamonds
âś… Get AvaCoins and Diamonds From avakin.vipgamehack.com Using This Tool
✔ Easy way to hack Avakin Life From gamepatch.org/avakin for AvaCoins and Diamonds
âś… 3 Step to get AvaCoins and Diamonds from avakinlifehack2018.top
🔥 avakin.fun has been update here. get AvaCoins and Diamonds for FREE!
âś… How to use bit.ly/2n8PWVh to get AvaCoins Diamonds Avakin Life


text:
As MisterLearnToCode says:
We can't ban offensive speech because then we'd be at the mercy of the most easily offended; the lowest common denominator, and wouldn't be able to discuss jack shit.
I especially want to people to have a place to say things they cannot say in person because of family or work or school pressure to conform to the politically correct opinions in their area.
If you are expressing a sincerely held point of view with good will, your comments and posts are very welcome here. If your point of view is "offensive" to others, that is excellent! Enjoy your freedom here. Please try to keep it about ideas and not about people. I love this Texas Congressman's philosophy about political debate:
Do not attack other users or the site itself. Personal attacks solve nothing, and in fact get us further away from solving anything. Examine what is said, not who speaks.
Try to acknowledge whatever truth there is in what the other person is saying before attacking the flaws in the argument.
If you don't like the site, go somewhere else. This site cost you nothing, was a lot of work for me, and doesn't even have advertising.
I often get requests to block "bad" people from the site, but don't believe that anyone is entirely bad or entirely good, only that the amount of each fluctuates over time.
If only it were all so simple! If only there were evil people somewhere insidiously committing evil deeds, and it were necessary only to separate them from the rest of us and destroy them. But the line dividing good and evil cuts through the heart of every human being. And who is willing to destroy a piece of his own heart?
― Aleksandr Solzhenitsyn, The Gulag Archipelago 1918–1956
Flag personal attacks with the "flag" link by each comment so that they will go into moderation where they will be reviewed by a moderator. Please do not flag comments just because you don't like them.
If you're wondering why your comment was flagged, please click the "edit" link on it. It should be pretty obvious when you read your own words again. If you think there was a mistake about the content's being flagged, please write firstname.lastname@example.com
If you're not registered or don't have the "flag" link, please report personal comments to email@example.com by email.
Here are the original articles that made this site famous:
There is an 8,000 character limit for both posts and comments.
If you ignore another user, you will not see his posts or comments. The ignore link is on their user page. Just click their name or icon to get to their user page.
To get another user's attention, mention him in a comment with an @ character prepended to his username ( for example @Patrick ) and then he will get an email of that comment.
If you include an image URL ending in .jpg, .png, or .gif it will be converted into the visible image in a post or comment.
If you include a youTube or Vimeo URL, the post or comment will display the video.
These basic html tags work: a b blockquote br code del font hr i iframe img li ol ol p strike sub sup u ul video vsmall
Surround a word or phrase with the * character to make it bold or the _ character to make it italic.
you can edit any post or comment you entered within a week of creating it. After a week, content is permanent and will not be deleted.
Please write email@example.com with questions or suggestions.
patrick.net has never received a national security letter.


text:
It's a common, and entirely justified complaint that most modern shooters look too drab. They're too brown, too grey, too dreary. You could counter that, well, since wars are fought in the dirt and ruins that's how they're supposed to look, but it's too nice a day for arguments.
Let's instead just enjoy this concept art from the recently-released Ghost Recon: Future Soldier, encompassing the work of Ubisoft artists Constance Beillard, Michel Donze and Fabien Roumazeilles (those links lead to each artist's personal site).
To see the larger pics in all their glory (or so you can save them as wallpaper), right-click on them below and select "open in new tab".
Fine Art is a celebration of the work of video game artists, showcasing the best of both their professional and personal portfolios. If you're in the business and have some concept, environment or character art you'd like to share, drop us a line!


text:
New SAS® Decision Manager Transforms Big Data Into Smarter Decisions
Posted: 12 June 2013 | Source: SAS
Single platform combines SAS strengths in information management and analytics.
It's simple: better, faster decisions boost bottom-line results. But how can organizations make better decisions with huge amounts of big data pouring into and through their systems? SAS® Decision Manager, from the leader in business analytics, integrates predictive analytics, business rules, and data management to help companies improve their decision-making.
With SAS Decision Manager, organizations can make sense of big data whether applying analytics to strategic decisions or everyday operational ones, such as credit, fraud risk, next-best offers, pricing and claims approval. By automating parts of decision-making processes, organizations improve the speed and accuracy of decisions and ensure they are consistent and repeatable.
Executives at one global financial services firm, for example, knew that better lending decisions reduced credit risk. Traditionally, the firm's analytics team had built a small number of models to predict loan repayment. Its IT team had then received the models, and customer data was fed in for analysis. Finally business staff approved loans based on the models' recommendations. These many steps and handoffs added time and costs to lending decisions.
SAS Decision Manager now allows the same company to feed data into a variety of relevant data models while eliminating manual handoffs between the teams. This has reduced the decision cycle from months to hours. And with SAS Decision Manager, loan decisions are constantly validated and modified based on ongoing input and further analytics.
SAS Decision Manager has also helped the business staff of this financial services firm to create business rules to determine how to use model output. The IT and business teams now use the most relevant models and business rules for loan decisions, and the speed and effectiveness of lending has increased significantly.
"The use of business rules as a foundation for decision management systems promotes agility by ensuring that business rules are transparent, easy to change and owned by the business," said James Taylor, CEO and Principal Consultant for Decision Management Solutions. "In this era of big data, organizations look for analytic insights to improve performance. They need an integrated decision life cycle supported by a common platform that drives collaboration among business, IT and analytics teams. SAS Decision Manager supports these requirements in a single integrated platform."
SAS Decision Manager provides a single, visual interface that:
- Integrates business rules, predictive analytic models and optimization with business processes.
- Provides a common decision-making environment.
- Centers decision design around a decision flow that supports analysis, simulation and reporting.
- Leverages existing SAS High-Performance Computing and big data infrastructure.
"We built SAS Decision Manager on an analytics platform to help organizations manage all their decisions, whether strategic or operational, in a single framework," said Madhu Nair, SAS Senior Manager for Information Management. "SAS Decision Manager delivers a consistent user experience and management environment that supports systems and workers throughout the organization. With it, companies can make faster, more accurate decisions that reduce costs, increase revenue, and bring innovative products to market ahead of competitors."


text:
Firefox for Android will not load pages on Android 4.0 (Ice Cream Sandwich)
Tega članka se ne vzdržuje več, tako da je njegova vsebina morda zastarela.
If you have the Android 4.0 (Ice Cream Sandwich) developer option - 'Don't keep activities' enabled, Firefox for Android won't load websites. Keeping this Android system setting enabled is not recommend as it may also result in undesireable behaviour in other Android applications.
Follow these steps to disable this setting:
- Open the Android settings app, scroll down and select and tap on Developer options
- Scroll down the list of Developer Options and uncheck the checkbox for 'Don't keep activities'
- If Firefox is running, quit it by returning to Firefox, tapping the menu on the upper right and choosing Quit.
- You can then relaunch Firefox and it should behave normally.


text:
challenge accepted, so below Christian de Sainte Marie wrote: > Dave, > > thanx for the clarification. > > Here is how I understand PRD needs, at this point. Please, all, > complete and/or correct me: > > 1. Production rules needs subclass relationships. But in most, if not > all, cases, the class hierachy is fixed and there is, therefore, no > need to test it explicitely. However, it may be used by classification > tests, and it is, thus, needed in the semantics. Since it is, in most, > if not all, cases, externally defined, it has to be imported. But the > import can be specified without requiring that subclass relationships > be explicitely asserted in rules or facts. > > Hence, (my current understanding is that) PRD can do without ## in the > concrete syntax. very odd to have ## in the abstract syntax and semantics but not let people use it. > > So, it would be interesting to challenge that assertion: > > 1a. What would be an use case where a subclass relationship test would > need be explicit in the condition of a rule (as opposed to the test > being carried silently as a consequence of importing the class > hierarchy)? Here's a production rule I'd very much like to write if I'm trying to translate between RDF and Java objects: if ?o # ?c1 and ?o # ?c2 and not(?c1 = ?c2 or exists( ?c ?o # ?c and ?c ## ?c1 and ?c ## ?c2)) then ConstraintViolation("found an object that cannot have a Java Object Model") > > 1b. What would be an use case where a subclass relationship would need > be explicitely asserted in a fact (as opposed to being taken into > account as a consequence of importing the class hierachy)? Let's say several vendors have RIF translators but not all have an import mechanism that works for Java objects, XML documents, and OWL ontologies. An enterprising vendor could build a comprehensive set of importers that output standard RIF so it can be used with all the current and future RIF translators (assuming the RIF dialect supports # and ## facts, of course) > > 1c. What would be an use case where a subclass relationship would need > be asserted as a consequence of a rule (as opposed to the class > hierachy being immutable)? I don't want to support this > > 2. Production rules need to test membership relationships, though. But > in most, if not all, cases, class membership is immutable. So that > class membership needs be asserted only at an object's creation. It > can thus be part of the semantics of the creation action (e.g. as > proposed in [1]). > > Hence, (my current understand is that) PRD can do with # being allowed > in tests and variable bindings only. No, we need # and ## as facts to support the Import Vendor use case. > > The only challenge to that assertion that I can imagine would be an > use case for class membership assignement or mutation as a consequence > of a rule (but you all know how poor my imagination :-) I don't want to support # and ## as conditional assertions, only as facts (i.e. unconditional) > > 2a. What would such an use case look like? > > 2b. Other ways to challenge the assertion, anyone? > Dave Reynolds wrote: >> >> The proposal we discussed some weeks ago (but seem never to have >> formally adopted) was to only have # and only in rule conditions. >> That is appealing to be me because then I don't have to implement >> anything (if you can't assert data you can't test it!). > > The semantics of PRD is specified with respect to a data source. But, > as far as I understand, it does not require the data to be explicitely > asserted as facts (as opposed to being imported by reference to the > data source). So that, as soon as we will have specified that import, > it will be possible, in PRD at least, to have facts to test class > membership, whether PRD allows to assert facts or not... > > Cheers, > > [1] http://www.w3.org/2005/rules/wiki/Alt_AbstrAction > > Christian >Received on Friday, 21 November 2008 21:27:47 UTC
This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:53 UTC


text:
Reviewed by Maria Duffy who says, "I've always wanted to gate-crash a party, so this is probably as close as I'll ever get! So for one day only, it's Maria reviewing here instead of Hazel. You might know me better from my Stars in the Twitterverse blog but having read Hazel's fabulous Titanic book, The Girl Who Came Home, I felt the urge to hop across the page and stick on Hazel's shoes! So let me turn the tables and put her in the spotlight – here's what I thought."
With the centenary of the sinking of the Titanic almost upon us, it's only right that we're reminded of one of the most awful maritime disasters in history. Hazel Gaynor's beautiful novel, The Girl Who Came Home, is not only a reminder of the actual disaster, but it's an exploration of human emotions – a gut-wrenching before and after look at lives that were forever changed on that momentous day. Hazel has based this novel on a true story of the Addergoole Fourteen, a group of men and women who left their small village in County Mayo inIreland to board the Titanic for its maiden voyage.
In Chicago in 1982, Grace Butler is looking for a story to write in order to revive her journalism career. She needs something big – something that will tap into the readers' emotions and get her noticed. But never in a million years was she expecting her great grandmother, Maggie Murphy, to be the one to provide her with what she's looking for. Maggie has kept a secret for seventy years and decides that now is the time to open up and share it with her great granddaughter.
And so the story takes us back to that rural Irish village in April 1912 when seventeen year old Maggie Murphy is preparing to sail on the Titanic, along with her aunt Kathleen and two of her best friends, Peggy and Katie. In all, fourteen men and women from the village are packing up their lives in hope of a better one over in America.
Maggie is excited about her impending voyage, but devastated to be leaving behind her beloved Seamus. She hopes he'll be able to join her soon in America but in the meantime, he's written a selection of love letters to keep her company on the journey ahead. These letters form part of this amazing story, where we learn what's going through the minds of some who have been left behind. Maggie also keeps a private journal during the sailing and it allows us a glimpse into her innermost thoughts.
Hazel's depiction of the characters in this novel is beautiful. She brings us right into their lives and we become invested in them. Although we know the fate of the ship, we're left rooting for the people we've come to know and hope that there's a way out for them. We also see the stories of some of those waiting on the other side – the relatives and friends who have gathered to hear news of the ill-fated ship. How unbearable it must have been to have to check a list of the dead, praying you wouldn't see your loved one's name on it.
Through all the mayhem on the ship, we follow Maggie and learn her fate, but it's only as the full scale of the disaster unfolds that we begin to learn the fate of the rest of the Irish group. Hazel manages to weave plenty of twists and surprises into the story and I have to admit to shedding a tear on a few occasions.
Forward to 1982 and Maggie and her great granddaughter decide to take a trip back to that little village in Ireland where it all began. Seventy years on, she feels it's about time she made peace with her past. It's an emotional scene as the past mingles with the present and we're left reeling as some unexpected plot twists reveal themselves.
If you're a lover of all things Titanic, you'll love The Girl Who Came Home, but if you just like a great emotional read with amazing, relatable characters, this is also the book for you. Hazel has managed to take a story that we've all heard a million times and give us a new perspective. Her attention to the detail of the ship made me feel I was there and her ability to portray the innermost thoughts of the characters meant I was fully invested in them and their safety. It's a thoroughly enjoyable read and I'd highly recommend it.
The Girl Who Came Home is available to download at the following link on Amazon.com or Amazon.co.uk Download to your Kindle reader, or download the free Kindle app for PC, iPad, iPhone or Android before downloading the book.
Hazel Gaynor is an author and freelance journalist, writing regularly for press, magazines and websites in the UK and Ireland. Her award-winning parenting and lifestyle blog, 'Hot Cross Mum' was published in 2011 as an ebook 'Hot Cross Mum: Bitesize Slices of Motherhood'. Hazel's writing success has been featured in The Sunday Times Magazine and Irish Times and she has also appeared on TV and radio.
Hazel writes 'Off The Shelf': a book review blog for hellomagazine.com, reviewing books by, and interviewing authors such as Jojo Moyes, Katie Fforde, Melissa Hill, Monica McInerney, Maria Duffy, Amy Chua and others.
'The Girl Who Came Home – A Titanic Novel' is Hazel's first novel. Originally from North Yorkshire, England, she now lives in Ireland with her husband, two young children and an accident-prone cat.
Hazel is represented by Sheila Crowley of Curtis Brown, London.


text:
ThomasCrown needed a new logo design and created a contest on 99designs.
A winner was selected from 26 designs submitted by 10 freelance designers.
I'm looking for a sexy, upscale logo for my new Vegas dating site, 7o2.com. Area code for Vegas is 702 (seven zero two), but this domain is 7o2(seven oh two). When creating the logo, think of casinos like the Palms and Hard Rock and clubs like Ghost Bar and Body English
Get Lucky in Vegas!
Desired Color Scheme:
2-3 colors max, nice contrast
Desired Style:
Sexy,Clean, Simple, Upscale
Accepted File Formats:
Simple color scheme (2-3 colors max), should look good in simple black and white. Simple design. Should have a sexy and upscale feel. Slogan for site is "Get Lucky in Vegas" so keep that in mind for the design.
Find out how a design contest works or learn more about our logo design services.