Web servisai (Security)

Web servisai (Security)
Tautvydas Dagys 2010

Introduction to WS Authorization
Brian P. Barrett Department of Computer Science University of Virginia Academic Advisor: Alfred C. Weaver Authorization - Authorization is the process of checking that a request implied by the receipt of a message, e.g. a SOAP Message is one that the sender of the message is allowed to make and therefore the request should be acted on by the service that receives it. WS-Authorization-WS Authorization is a specification that IBM and Microsoft plan to develop that will "describe how to manage authorization data and authorization policies". See IBM and Microsoft's Security Roadmap. CS 551

Authorization WS-Authorization Steps of Authorization
Security Token Acquisition SAML Authorization in Firewall Map of Authorization Authorization in Code References WS- Authorization isn’t complete, so I will first touch on what the status on this web service is and how its coming along. Since its not complete my examples on using the web-service will be limited. However I will show its uses with Authorization data and where it fits in the WS-Security Frame work. The responsibilities of Authorization in this web service include managing policies of different accounts and their policies. CS 551

Where does Authorization fit in?
Authorization is an aspect of security that falls in with other categories: Secure Conversation Federation Policy Trust Privacy Is this Authorized? Authorization is planned to manage authorization and data polocies amongst the WS-Security building block. These sections are all Web Services. However, Authorization is incomplete and I will show you what they hope to accomplish with Authourization and what is the reason for its late departure with the other Security Services. CS 551

Security Authentication Determine identity of a person/object
Authorization Determine what the person is allowed to do Integrity Ensure the data was not altered on its way to you Signature Validate the source of the data Confidentiality Limit the people allowed to view the data Privacy Make sure no one abuses your data Digital Rights Management Limit users from doing whatever they want CS 551

How does Authorization work with other services?
If Authorization were to be on a layer working with other Services. It would work in conjunction with the Federation layer. WS-Federation WS-Secure Conversation WS-Authorization This specification will describe how access policies for a Web service are specified and managed. In particular it will describe how claims may be specified within security tokens and how these claims will be interpreted at the endpoint. This specification will be designed to be flexible and extensible with respect to both authorization format and authorization language. This enables the widest range of scenarios and ensures the long-term viability of the security framework. Authorization just like the other 3 building blocks, works in conjuction with different clients working together to ensure safe and secure web services. WS-Federation works for standardizing the way companies share user and machine identities among disparate authentication and authorization systems spread across corporate boundaries. CS 551

Authorization with other WS
CS 551

Explain diagram and Authorizations purpose in the building blocks.
Information that’s being exchanged to improve Authorization includes data and policies from Privacy and Trust. In particular it will describe how claims may be specified within security tokens and how these claims will be interpreted at the endpoint." Privilege Management Infrastructure: Source of Authority (SOA) = The topmost root of trust, sometimes also referred to as trust anchor Attribute Authority (AA) (also Privilege Allocator, Authoritative Entity) = The issuer of an attribute certificate Certificate Holder / Privilege Holder = The User or Subject of an Attribute Certificate CS 551

PMI or Privilege Management Infrastructure
Source of Authority (SOA) = The topmost root of trust, sometimes also referred to as trust anchor Attribute Authority (AA) (also Privilege Allocator, Authoritative Entity) = The issuer of an attribute certificate Certificate Holder / Privilege Holder = The User or Subject of an Attribute Certificate Authorization information may be placed in a PKC extension or placed in a separate attribute certificate (AC). The placement of authorization information in PKCs is usually undesirable for two reasons. First, authorization information often does not have the same lifetime as the binding of the identity and the public key. When authorization information is placed in a PKC extension, the general result is the shortening of the PKC useful lifetime. Second, the PKC issuer is not usually authoritative for the authorization information. This results in additional steps for the PKC issuer to obtain authorization information from the authoritative source. Yet, authorization information also needs to be bound to an identity. An AC-Attirubution Certificate provides this binding; it is simply a digitally signed (or certified) identity and set of attributes. This will probably mean that Authorization will work closely with Authentication and Trust Services. CS 551

Security Token Authorized
The Web Service Obtains security Token The Data and policies will be Validated for that Particular client Requestor Issues a request. Web Service Trusts Established. Request was Processed and response returned Auth and Trust are Validated. Service must find Data and policies that are authorized for the user. In some cases, the security token used isn't passed as part of the message. Instead, a security token reference is provided that can be used to locate and acquire the token. To explain Authorization, Security Token Acquisition above explains the different steps in taking and authorizing information. The image above explains that there may be problems when a person from the outside of a company firewall might want to access some secure information that will require authorization. This will require a security token that has to be issued to the outside client. This token will allow the user to authorize his personal/ authorized settings. Here- I will explain a real life example with a Liberty Mutual and why they may need VPN/SSL services to keep a secure to connection to its data and their authorized information. Step 1 -The requester issues a request to the service and includes a reference to the security token and provides proof-of-possession. Step 2 - The Web service uses the provided information to obtain the security token from the token store service and validate the proof. Step 3 - The Web service trusts (note that trust was established outside of the message semantics) the security token, so the request is processed and the response is returned. Step 4 – Once the Authentication and Trust Services are validated, the data given from the Service- now must find the data authorized that the client may browse. Step5 – When validated the data and policies for that particular client will be enabled and browsed for the client. CS 551

SAML – Security Assertion Markup Language
SAML’s purpose was to be a Security language that could be used as an industry standard for security. It uses XML digital signatures with XML encryption. The languages uses assertions made in the code that can convey information about authentication functions, and authorization decisions. The OASIS TC has been chartered to "define an XML framework for exchanging authentication and authorization information" and previously published working drafts for the Security Assertion Markup Language (SAML). SAML with Authorization is used to share authentications for a “single sign on”. Enable Third party sign on authentications. Assertions can convey information about authentication acts performed by subjects, attributes of subjects, and authorization decisions about whether subjects are allowed to access certain resources. Assertions are represented as XML constructs and have a nested structure, whereby a single assertion might contain several different internal statements about authentication, authorization, and attributes.“ Its primary goal is to provide a mechanism by which permissions management data can be shared in a standardized fashion across domains and across a variety of systems and thus provide for interoperability. Among other scenarios, this enables single sign-on functionality for distributed systems. Its prime focus are web services. A standard XML message format for SAML requests, assertions and responses is provided SAML replaces two previous efforts by OASIS to create an authorization and authentication protocol, called S2ML and AuthXML. These efforts were being carried out by separate camps, but the SSTC decided it was in everyone's best interests to get all of the camps under one spec and combined the two efforts, because they handled two separate functions. Code example : CS 551

SAML Authorization Map
Explain Diagram. CS 551

PEP- Policy Enforcement Point
Definition Dependence upon the resource PDP-Policy Decision Point PEP - A component of a resource manager that is responsible for performing authorization queries against the Policy Decision Point and enforcing the resulting Authorization Decision Assertions. PDP – The place where a decision is arrived at as a result of evaluating the requester’s authorization attributes, the requested operation, and the requested resource in light of applicable authorization policy. CS 551

Authorization in Firewall Processing
Insurance Co. Claims officer/ Customer Firewalls remain a critical component of the Web services security architecture—they must be able to continue to enforce boundary processing rules. As shown below, the firewall examines incoming SOAP messages and only allows those from "authorized" requesters to penetrate the firewall. In this scenario we have two requesters sending messages to a Web service inside a firewall. The firewall examines the messages to determine if the requester is "authorized" to send messages to the specified Web service inside the firewall. In this scenario, the firewall makes this decision by examining the security token used to sign the message. If the signature is valid, and the signing authority for the security token is trusted to authorize messages into the firewall, and the token says that it does authorize messages into the firewall, then the message is allowed; otherwise it is rejected. In some cases, a signature may specifically reference the firewall as a SOAP actor. In other scenarios the firewall could also act as a security token issuing authority and only allow messages that include proof-of-possession of a security token issued by the firewall. Web-Service CS 551

Authorization Process Map
Client -Give server trust -Invocate policy -consult policy Server Access Policy Give client resource Policy authority Authorization Process Role based Authorization Instance based Authorization Capability listings Explain chart above and how the different components work together with Authorization Key Terms: RBAC(Role based Authentication)- Constraints are an important aspect of role-based access control (RBAC) and are often regarded as one of the principal motivations behind RBAC. Although the importance of constraints in RBAC has been recognize zed for a long time, they have not received much attention. In this article, we introduce an intuitive formal language for specifying role-based authorization constraints named RCL 2000 including its basic elements, syntax, and semantics. This language language provides us a rigorous foundation for systematic study of role-based authorization constraints. An example of an RBAC is PERMIS. PERMIS uses a role based access control (RBAC) scheme that allows privileges to be associated with roles rather than with specific entities. Entities can then hold several roles. X.509 attribute certificates to securely bind and communicate role membership among the components of the infrastructure. Access requests are evaluated via an authentication, authorization and accounting (AAA) server which provides two main functionalities: an access control decision function (ADF) and an access control enforcement function. Instance Based- [Will explain authorization here] CS 551

How does the the Authorization code fit?
CS 551

Code Example <Rule RuleId="//medico.corules/rule3" Effect="Permit"> <Target> <Subjects> <saml:Attribute AttributeName="RFC822Name" AttributeNamespace="//medico.com"> <saml:AttributeValue>*</saml:AttributeValue> </saml:Attribute> </Subjects> <Resources> <saml:Attribute AttributeName="documentURI" AttributeNamespace="//medico.com"> <saml:AttributeValue>//medico.com/records.*</saml:AttributeValue> </saml:Attribute> </Resources> <Actions> <saml:Action>read</saml:Action> </Actions> </Target> <Condition> <Equal> <AttributeDesignator AttributeName="urn:oasis:names:tc:xacml:identifiers:AccessSubject" /> <AttributeDesignator AttributeName="patientName" /> </Equal> </Condition> </Rule> CS 551

References Primary Secondary
Globus is a resource to see the latest changes with WS-Authorization and other new standards. If you go here and choose XML Security under Lecture slides you will find some detail about coding with SAML and its interaction for Authorization processes. Secondary us/dnwssecur/html/securitywhitepaper.asp Here you will fine some significant images that detail security over the web. At this site you can learn new technology dealing with XML, SAML and XMACL. CS 551

WS-SecureConversation
Xiuduan Fang Department of Computer Science University of Virginia

Agenda Introduction Security Context Token
Establishing Security Context Deriving Keys SecureCoversation in Action Conclusion References

Introduction to WS-SecureConversation
Why introduce WS-SecureConversation? Consider the functions of WS-Security message integrity message confidentiality single message authentication Note that WS-Security specification focuses on the single message authentication model.

What if senders and receivers need to exchange multiple messages? A sender and receiver, who don't inherently trust each other, need to send/receive messages that can't be read by unintended entities

A Feasible Solution Encrypt all messages with a security token issued by a token issuing service. Drawback: the size of each message can become a performance bottleneck. Message size may not be a problem for short-lived one-way message scenarios, but it can become a performance bottleneck when the senders and receivers are engaging in multi-message communication (e.g. orchestration).

A Better Solution WS-SecureConvsation Similar to SSL Introduce a security context A SecurityContextToken is applied. Once created, the messages are smaller and can be processed faster by both ends. Secure conversation provides Web service architectures a similar level of security and performance that SSL (TLS) provides HTTP. In much the same way SSL establishes a session key, secure conversation uses security tokens based on the context in which they're used. A SecurityContextToken is applied in this context the way KerberosToken, X.509SecurityToken, and UsernameToken have been used in our other scenarios. Each of these classes ultimately inherits from the SecurityToken base class. In the same way symmetric keys are negotiated in SSL, there is upfront overhead in creating the SecurityContextToken, but once this is done the messages are smaller and can be processed faster by both ends.

Goals Define how security contexts are established Specify how derived keys are computed and passed Non-Goals Define how trust is established or determined—that is done by WS-Trust

Introduction Introduction Security Context Token
Establishing Security Context Deriving Keys SecureConversation in Action Conclusion References

Security Context Token
<SecurityContextToken> describes a security context.

Syntax of Security Context Token
<wsse:SecurityContextToken wsu:Id="..."> <wsu:Identifier>...</wsu:Identifier> <wsu:Created>...</wsu:Created> <wsu:Expires>...</wsu:Expires> <wsse:Keys> <xenc:EncryptedKey Id=“…”>… </xenc:EncryptedKey> <wsse:SecurityTokenReference>... </wsse:SecurityTokenReference> ... </wsse:Keys> </wsse:SecurityContextToken> /SecurityContextToken This element is a security token that describes a security context. /SecurityContextToken/wsu:Identifier This required element identifies the security context using a URI. Each security context URI be MUST be globally unique to both the sender and recipient. /SecurityContextToken/wsu:Created This optional element indicates the creation time of the security context. This is typically only specified on the first usage of the token. That is, it is typically cached as part of the context by the recipient. /SecurityContextToken/wsu:Expires This optional element indicates the expiration time of the security context according to the requestor's clock. This is typically only specified on the first usage of the token. That is, it is typically cached as part of the context by the recipient. /SecurityContextToken/Keys This optional element holds the shared secrets of the security context. This is typically only specified on the first usage of the token. That is, it is typically cached as part of the context by the recipient. If there is no <Keys> element, then the shared secret is assumed to be already known and associated with the security context identified by the URI specified in the <Identifier> element. /SecurityContextToken/Keys/xenc:EncryptedKey This optional element holds the shared secret of the security context. This optional attribute specifies an "ID" for the key. Note that this does not use the wsu:Id attribute because the schema doesn't allow for attribute extensibility. /SecurityContextToken/Keys/SecurityTokenReference This optional element references the shared secret of the security context. /SecurityContextToken/Keys/{any} This is an extensibility option to allow other types of keys/tokens to be specified. This optional attribute specifies a string label for this element. This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the element. /SecurityContextToken/{any} This is an extensibility mechanism to allow additional elements to be used.

Security Context Token Example
<wsse:SecurityContextToken wsu:Id="SecurityToken- f3dfe69f-4bd6-41f9-b198-bb6247d14780"> <wsu:Identifier>uuid:f1971e12-f d-bf7d- 29c78a0a81eb </wsu:Identifier> <wsu:Created> T02:52:55Z</wsu:Created> <wsu:Expires> T06:52:55Z</wsu:Expires> </wsse:SecurityContextToken> /

Establishing Security Context
A security context needs to be created and shared by the communicating parties before being used. How? created by a security token service (STS) created by one of the communicating parties and propagated with a message created through negotiation

Way 1: Created by STS The context initiator asks a security token service to create a new security context token. The newly created security context token is distributed to the parties through the protocols defined here and in WS-Trust. For this scenario the initiating party sends a <RequestSecurityToken> request to the token service and a <RequestSecurityTokenResponse> is returned. The response contains a <SecurityTokenReference> pointing to the new security context token and a <ProofTokenReference> pointing to the "secret" for the returned context. 3. In contrast to encrypted messages sent in a normal token issuing scenario based solely on WS-Trust, the messages signed/encrypted with a SecurityContextToken have a substantially smaller payload.

<RequestSecurityToken> Example
<S:Body wsu:Id="req"> <RequestSecurityToken> <TokenType>wsse:SecurityContextToken</TokenType> <RequestType>wsse:ReqIssue</RequestType> </RequestSecurityToken> </S:Body>

<RequestSecurityTokenResponse> Example
<S:Body> <RequestSecurityTokenResponse> <RequestedSecurityToken> <wsse:SecurityContextToken> <wsu:Identifier>uuid:...</wsu:Identifier> </wsse:SecurityContextToken> </RequestedSecurityToken> <RequestedProofToken> <xenc:EncryptedKey Id="newProof"> ... </xenc:EncryptedKey> </RequestedProofToken> </RequestSecurityTokenResponse> </S:Body> The response contains a <SecurityTokenReference> pointing to the new security context token and a <ProofTokenReference> pointing to the "secret" for the returned context. The response is encrypted.

Way 2: Created by One of The Communicating Parties
Process The initiator creates a security context token and sends it to the other parties in a message The recipient can then choose whether or not to accept the security context token Application This model works when the sender is trusted to always create a new security context token. The initiator creates a security context token and sends it to the other parties on a message using the mechanisms described in this specification and in WS-Security. This model works when the sender is trusted to always create a new security context token. For this scenario the initiating party creates a security context token and issues a signed unsolicited <RequestSecurityTokenResponse> to the other party. The message contains a <SecurityTokenReference> pointing to the new security context token and a <ProofTokenReference> pointing to the "secret" for the security context token. The recipient can then choose whether or not to accept the security context token.

Way 3: Created through Negotiation
Process The initiating party sends a <RequestSecurityToken> request to the other party A <RequestSecurityTokenResponse> is returned. Repeat the above 2 steps until a final response containing a <SecurityTokenReference> and a <ProofTokenReference> is received. Application There is a need to negotiate among the participants on the contents of the security context token, such as the shared secret When there is a need to negotiate among the participants on the contents of the security context token, such as the shared secret, this specification allows the parties to exchange data to establish a security context. For this scenario the initiating party sends a <RequestSecurityToken> request to the other party and a <RequestSecurityTokenResponse> is returned. It is likely that the negotiation (challenge/response) semantics described in WS-Trust will be used. Ultimately (if successful), a final response contains a <SecurityTokenReference> pointing to the new security context and a <ProofTokenReference> pointing to the "secret" for the context.

Deriving Keys Once the context and secret have been established (authenticated), Derived Keys Mechanism can be used to compute derived keys for each key usage in the secure context. Example Four keys may be derived so that two parties can sign and encrypt using separate keys.

Deriving Keys Algorithms
Using a common secret, parties may define different key derivations to use Default: P_SHA-1 function (referred to as wsse:PSHA1) P_SHA1 (secret, label + seed) The P_SHA-1 function is used with three values – secret, label, and seed. The secret is the shared secret that is exchanged (note that if two secrets were securely exchanged, possible as part of an initial exchange, they are concatenated in the order they were sent/received). The label is the concatenation of the client's label and the service's label. These labels can be discovered in each party's policy (or specifically within a <DerivedKeyToken> token). If either isn't specified in the policy, then a default value of "WS-SecureConversation" is used. The seed is the concatenation of nonce values that were exchanged (initiator + receiver). The nonce seed is required, so nonces MUST be exchanged. The P_SHA-1 function has two parameters – secret and value. We concatenate the label and the seed to create the value.

Deriving Keys The <DerivedKeyToken> element is used to indicate that the key for a specific security token is generated from the function of P_SHA-1. Example <DerivedKeyToken> <SecurityTokenReference> <Reference URI=".../ctx1"/> </SecurityTokenReference> <Generation>2</Generation> </DerivedKeyToken> This example illustrates a derived key based on the 3rd generation of the shared key identified in the specified security context. It should be noted that the value of <generation> element specify which generation of the key to use(beginning with zero).

Subsequent Derivation Example
<DerivedKeyToken> <Properties> <Name>.../derivedKeySource</Name> <Label>NewLabel</Label> <Nonce>FHFE...</Nonce> </Properties> <Generation>3</Generation> </DerivedKeyToken> <DerivedKeyToken wsu:Id="newKey"> <SecurityTokenReference> <Reference URI=".../derivedKeySource"/> </SecurityTokenReference> <Generation>0</Generation> In order to keep the keys fresh, subsequent derivations may be used. The example illustrates a derived key based on the 1st generation of a key derived from an existing derived key (4th generation): We have named a derived key so that other keys can be derived from it. To do this we use the <Properties> element name tag to assign a global name attribute. Note that in this example, the ID attribute could have been used to name the base derived key if we didn't want it to be a globally named resource. We have also include the <Label> and <Nonce> elements as metadata properties indicating how to derive sequences of this derivation.

Predefined Security Tokens

Conclusion of WS-SecureConversation
The WS-SecureConversation specification defines extensions to allow security context establishment and sharing, and session key derivation.

Primary References us/dnglobspec/html/ws-secureconversation.asp Official specification describing WS-SecureConversation us/dnwse/html/wssecdrill.asp A good reference that explains how to use Web Services Enhancements 2.0 to implement security, trust, and secure conversations in Web services architecture.

Secondary References 4C95-87B7-FC7AB49B3EDD&displaylang=en The WSE 2.0 technology preview provides early access to new advanced Web services capabilities. The latest advanced Web services capabilities to keep pace with the evolving Web services protocol specifications.

Temos pranešimams REST CLOUD SOA WS-Federation

Web servisai (Security)

Similar presentations

Presentation on theme: "Web servisai (Security)"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Web servisai (Security)

Similar presentations

Presentation on theme: "Web servisai (Security)"— Presentation transcript:

Similar presentations

About project

Feedback