Archive for the ‘SAML’ Category

SAML Tutorial

December 18, 2007

What is SAML

Authenticating web service calls with SAML

PAWN was designed to operate across multiple administrative domains. For example, in our archive testbed, we already have NARA, UMIACS, SDSC, and and handful of other partners. Each partners is accepting data from various outside groups. In this environment, it is not feasible to enforce any type of centralized authentication service. This presents a problem when a NARA partner wants to use a resource at UMIACS. Assuming that UMIACS doesn’t have the ability to directly authenticate against NARA, how does a partner that can authenticate against NARA use UMIACS resources. In our case, the answer is to use SAML assertions.

A SAML assertion is just an XML file that contains information about who issued it, some statements about some (name, access priveleges, etc), and information to entire entegrity of the token and trust of the client. To access a remote resource in our example, an assertion is issued by NARA to the partner upon successful authentication at NARA (kinda kerb ticket like). The partner can then show that assertion along with proof that it’s allowed to use that assertion to the UMIACS resource, and UMIACS will allow access. Of course there are layers of signatures, and key exchanges that go on under the hood to enable this and keep everything secure.

We use the WS-Security standard to enable initial authentication by username / password, and to handle SAML authenticated methods. In addition, we have some libraries to allow the generation and checking of SAML tokens. We’ve chosen to use the SAML 1.1 specification, and the OpenSAML toolkit.

This just covers how we use SAML tokens in the ADAPT project. There is a lot more to the specification than what we use. This includes token request services, and different types of token workflows. This is described at OASIS Security Services (SAML) TC page.

SAML Assertion

So, what is needed to allow SAML tokens, and what do these tokens contain?

A SAML assertion is nothing more than a bunch of statements about the holder of the assertion. In our case, we use an assertion that contains a single statement of type Attribute Statement. This statement includes who a client is, and what role they are to perform in ADAPT.

A SAML assertion contains several parts, first is the assertion envolope that contains all statements and information about lifecycle and assertion integrity.

Assertion Container

Since the assertion is just a container for statements, the only piece of information we really care about is lifetime for an assertion and integrity information. Lifetime is done with a global Conditions statment that contains a start and end date for the validity of this certificate. The container also contains the issuer of the assrtion.



The integrity of an assertion can be checked by looking at the SignatureValue and KeyInfo sections. These contain the digital signature of the assertion and the certificate used to verify that signature. In PAWN, this would be the public key at a producer site, or scheduler. You can use this key to validate the integrity of certificate during transport, if you use the embedded key, you must check the signing path of that cert back to some trusted certificate authority. You will also need to check that the key is one that you expect (ie, not a different one signed by the same CA). In PAWN, we use a simplier system, each service that consumes these assertions will have a local copy of the Authorities certificate that they can validate the certificate against.

Services that will trust a site’s assertions will need to get it’s keys ahead of time. In an archive environment this exchange is feasable since the trust is largely between a central archive and remote sites, not necessarity between each remote site and every other site. There are project such as the Liberty Alliance and Shibboleth that address some of these issues.

CvL4...



MIIC...


Subject

The subject contains a NameIdentifier that gives us two pieces of information. First is has a NameQualifier, this is the domain or realm that this use belongs to. Second, it contains the identity of the user. We just use a plain text username here, but it’s possible to embed any other information, ldap DN, xml, etc.

In PAWN, the nameQualifier is used to specify the domain of an individual user. In combination with the issuer, the namequalifier and actual value specify a unique entity.

rlopez

Second a subject contains confirmation information. In our case, this the assertion uses holder-of-key as a method for clients to prove they are the rightful owner of this certificate. There are additional confirmation methods, some of which are listed on Sun’s xws tutorial Below the confirmation method, is a certificate that will be used for this. Holder-of-key says that a client must prove they are allowed to use this certificate by showing they have a private key corresponding to the certificate. In the case of web services, the private key proof is to sign the entire SOAP message with the private key, then verify that signature against the embedded cert.

Here is a what the subject confirmation part of a subject looks like:


urn:oasis:names:tc:SAML:1.0:cm:holder-of-key


MIID...



Since the entire SAML token is by the issuer, and this signature can be verified, we can ensure that nobody changed the embedded certificate or other information and can trust what it says.

Attributes

We use attribute statements in ADAPT to send a list of all privileges a user has for a given package. a privilege in PAWN is divided into two parts, first is the type of privilege, and second is the action on that type. For example. ‘Package Item’ may be the type and ‘Modify’ may be the allowed action. The type is represented by the AttributeName and the action is represented by a list of AttributeValues. There are two special types that do not follow this pattern.

  • package_id – contains the manager id number of the package as it’s AttributeValue.
  • package_structure – contains a record set document as its value.

Since the roles have to cross sites they need to have a common namespace. We’ve started outlining some available roles [[Main.SamlRoles][here]]. Of course a 3rd party is allowed to ignore roles that it doesn’t seem fit. For example, the scheduler may only allow certain issuers to modify resource configuration.

Standard type and action


view
create
modify
delete

Special package_id attribute


1

Entire Assertion

The complete assertion that is used for authentication looks as follows:

<Assertion xmlns="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" AssertionID="fd653abed9ae5bcb59ab3665a149ab9f"
IssueInstant="2005-07-15T16:57:42.047Z" Issuer="http://umiacs.umd.edu" MajorVersion="1" MinorVersion="1">






rlopez

urn:oasis:names:tc:SAML:1.0:cm:holder-of-key


MIID...






urn:pawn:role:user














<ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
PrefixList="code ds kind rw saml samlp typens #default">




vl8p6+i7ITSqRqqluuNwPTevwC0=



CvL4...



MIIC...






Workflow

The workflow for using SAML authentication in PAWN follows:

  1. Any service that will trust a 3rd party Authority will need a copy of it’s certificate
  2. Each site will need to have certificates of any certificate authority used.
  3. A client connects to an Authority and authenticated with local security information (username/password) and supplies a certificate that it will use to prove it’s identity.
  4. The Authority authenticates the client and verifies the supplied certificate against CA certificate.
  5. Authority create assertion with client roles, identity, supplied cert, signed the assertion and returns to client.
  6. (optional) If a client doesn’t trust the transport to the Authority, it can validate the assertion.
  7. A client connects to a 3rd party web service. The SOAP message contains the SAML assertion in the header plus a signature of the soap message. Signature is created with private key corresponding to embedded cert.
  8. The consuming service verifies the message signature was generated with the embedded cert, it also checks the saml signature against the Authorities certificate that is has locally.

You can see the sample SAML application here

Complete Info Here

Authenticating Web Services with SAML

What is SAML : Ten Facts You Need To Know

SOAP::Lite for Perl

Call SOAP Web services with Ajax, Part 1: Build the Web services client”


LifeLock Identity Theft Prevention - Save 10%

Courtesy:http://adaptwiki.umiacs.umd.edu/twiki/bin/view/Lab/SamlTutorial

Reverse Proxy Functionality

November 6, 2007

Reverse Proxy Overview
A reverse proxy server is a server that acts as a broker between two entities, validating and processing a transaction in such a way that the actual parties to the transaction do not directly communicate with one another. This means that the proxy acts on behalf of the content web server. Typically, reverse proxy servers reside outside a firewall to represent a secure content server to outside clients, preventing direct, unmonitored access to the internal server’s data.

If you have a content server that has sensitive information that must remain secure, such as a database of credit card numbers, you can set up a reverse proxy outside the firewall as a stand-in for your content server. When outside clients try to access the content server, they are sent to the proxy server instead. When a client makes a request to your site, the request goes to the reverse proxy server. The reverse proxy server then sends the client’s request through a specific passage in the firewall to the content server. The content server passes the result through the passage back to the proxy. The proxy sends the retrieved information to the client, as if the proxy were the actual content server. In addition, the reverse proxy captures any URLs listed in the headers before sending the message to the client; this prevents external clients from getting redirection URLs to the internal content server.

Secure Reverse Proxying
Secure reverse proxying occurs when one or more of the connections between the proxy server and another machine uses the Secure Sockets Layer (SSL) protocol to encrypt data. Secure reverse proxying can provide an encrypted connection from a proxy server outside a firewall to a secure content server inside the firewall. It can also clients to connect securely to the proxy server, facilitating the secure transmission of information (such as credit card numbers).

Client Authentication
In addition to SSL, the proxy can use client authentication, which requires that a computer making a request to the reverse proxy authenticate with a username and password before their request is permitted.

Configuring a Reverse Proxy
Reverse proxies are configured via the virtual hosts configuration panel. Essentially, a virtual host, i.e. corp.sambar.com, is configured to forward requests to: http://internal.corp.sambar.com (or https://internal.corp.sambar.com for secure reverse proxying). Additionally, you can configure Require Authentication to ensure all requests to the virtual host authenticate; the virtual host can identify the authentication mechanism (LDAP, Radius, passwd).

More Here

Courtesy:http://www.sambar.com/syshelp/revproxy.htm

What is SAML

June 19, 2007

What is SAML?

SAML stands for the Security Assertions Markup Language
SAML has been developed by the Security Services technical committee of the OASIS standards organization. It provides a standard for exchanging security information about users over the Internet.
SAML is based on XML messages called assertions. Assertions contain information that determine whether users can be authenticated or authorized to use resources. SAML enables single sign-on across trusted domains, such as Web sites or Web Services.

How does SAML exchange security information?
SAML is often illustrated through scenarios in which SAML is used to share authentication and authorization information between parties. The following procedure describes one of these scenarios:
1. User contacts a SAML Authority to obtain a SAML assertion.
2. SAML Authority authenticates the user and issues a signed assertion that specifies which resources (Web sites or Web Services) the user can access.
3. User issues a request containing this assertion to one of the specified Web Services.
4. The receiving Web service uses the assertion to allow the user access without authentication.
Rather than authenticating the user, the SAML Authority signature is examined to ensure that the assertion is valid and has been issued by a trusted SAML authority.

Types of SAML Assertion
In addition to providing authentication information about a user, assertions can provide authorization information. The following describes the different types of SAML assertion:

• Authentication assertion
Contains authentication decisions made about the user. Web sites or Web Services can use this type of assertion as a basis for authenticating a user. An example of how this type of assertion can be used is shown in the previous screen.

• Authorization assertion
Contains authorization decisions made about the user. Web Services use this type of assertion as a basis for granting users authorization. For example, the assertion may state that the user has read access to whitepapers. For this type of assertion to be meaningful, the same types of permission and types of resource must be used by the Web service that created the assertion and the service that uses the assertion to authorize users.

• Attribute assertion
Contains attributes for a user that can be used to determine authorization. Examples of attributes include the identity of a user, and the type of access that the user has been allowed. Web Services use this type of assertion to decide whether a user should be authenticated and the level of authorization they should be granted. Unlike the other two types of assertion, this does not contain decisions that have already been made about the user.

Courtesy:http://www.vordel.com/knowledgebase/tutorial_xml_security/XMLS22.html

SAML (Security Assertion Markup Language )

May 28, 2007

Security Assertion Markup Language (SAML) is an XML standard for exchanging authentication and authorization data between security domains, that is, between an identity provider (a producer of assertions) and a service provider (a consumer of assertions). SAML is a product of the OASIS Security Services Technical Committee.

The single most important problem that SAML is trying to solve is the Web Browser Single Sign-On (SSO) problem. Single sign-on solutions are abundant at the intranet level (using cookies, e.g.) but extending these solutions beyond the intranet has been problematic and has led to the proliferation of non-inter-operable proprietary technologies. SAML has become the definitive standard underlying many web Single Sign-On solutions in the enterprise identity management problem space.

SAML assumes the principal (often a user) has enrolled with at least one identity provider. This identity provider is expected to provide local authentication services to the principal. However, SAML does not specify the implementation of these local services; indeed, SAML does not care how local authentication services are implemented (although individual service providers most certainly will).

Thus a service provider relies on the identity provider to identify the principal. At the principal’s request, the identity provider passes a SAML assertion to the service provider. On the basis of this assertion, the service provider makes an access control decision.