SAML and Security
Federation:
Federation describes scenarios in which no group or organization manages all users and resources in a distributed application environment. Instead, administrators in diverse domains must manage local security policies that support mutually beneficial transactions among their respective spheres of operation. In the world of distributed network services, the term refers to the need for trust agreements among decentralized security and policy domains. Federation lets access-management functions span diverse organizations, business units, sites, platforms, products and applications. Federation requires that an organization trust each trading partner to authenticate its own users' identities. In a federated environment, a user can log on to his home domain and access resources transparently in external domains, such as those managed by customers or suppliers, subject to various policies defined by home and external administrators.Federation used with a new security standard, the XML-based Security Assertions Markup Language (SAML). The standard defines XML/Simple Object Access Protocol-based protocol interactions that support real-time authentication and authorization across federated Web services environments. The standard defines request and response messages that security domains use to exchange authentication, attribute and authorization information in the form of trust-assertion messages about named users and resources. Users log on to their home domains through authentication techniques such as ID/password or Kerberos, and this authentication is communicated to a federated destination site through a SAML authentication assertion.
How SAML works
One of the most important of those security issues is user authentication - specifically, allowing a user to sign on or use multiple Web services from separate but affiliated sites, without having to authenticate himself at every step of the process. That's the job of SAML (Security Assertion Markup Language), an XML-based standard for authentication and authorization that provides a "single sign-on" so that people can be authenticated once and then be able to access multiple Web services. SAML allows each individual site to have its own mechanism for sign-on and authentication, but will allow sites to accept authenticated users from other sites.
Why SAML is needed
Before we take a look at how SAML works, let's take a look at why it's needed. Let's say someone visits an airline site with a Web services architecture, and reserves tickets after signing on and being authorized to buy the tickets. The site offers special deals with partner sites on hotel stays and car rentals, and so the user decides to make reservations with them. In order to make reservations with each of those partner sites without SAML, the person will have to sign on separately to each site, using different user names, passwords and authentication information. He also might have to enter special codes that say he is entitled to the special deals. But with SAML, the person would only have to sign on to the first site, and he would then automatically be authenticated via SAML at the affiliated sites.Even more problematic are complex B2B transactions done via Web services. Web services will most likely be used in automated transactions that involve multiple business partners, including manufacturers, distributors, packagers, suppliers and retailers. With no way to authenticate each partner and what they can and can't do in a transaction, these transactions won't be able to be done automatically. With SAML handling authentication, complex transactions can be automated without worrying about authentication problems.
SAML Implementation
So how does SAML tackle all this? At its base, SAML is nothing more than a series of XML-based messages that detail whether users are authenticated, what kind of rights, roles and access they have and how they can use data and resources based on those rights and roles. It will work with HTTP, SMTP, FTP and SOAP, among other protocols and technologies.
The three main components of the SAML specification are:
Assertions SAML has three kinds of assertions:
1. Authentication assertions are those in which the user has proven his identity.
2. Attribute assertions contain specific information about the user, such as his spending limits.
3. Authorization decision assertions identify what the user can do, for example, whether he can buy an item.
Protocol:
This defines the way that SAML asks for and gets assertions, for example, using SOAP over HTTP for now, although using other methods in the future.
Binding: This details exactly how SAML message exchanges are mapped into SOAP exchanges.
The assertions are exchanged among sites and services using the protocol and binding - and those assertions are what authenticates users among sites.
SAML in real life
How does SAML work in real life? Let's take a real-life example. Say someone logs in and uses a Web service, is authenticated and then wants to go to a partner site. With SAML, he can be authenticated at the second site without having to sign on. The nearby figure shows each step of the process:
Step 1 the user has authenticated himself with Site 1 and wants to visit Site 2. He clicks on a link to go to Site 2.In
Step 2, instead of being sent straight to Site 2, he is instead sent to the SAML service for Site 1.
Step 3 the SAML service appends a partner ID and a special handle to Site 2's URL in the user's browser.
For example, if the user wants to go to the site http://www.buymenow.com, after the SAML service appends the extra information, the URL might now be https://www.buymenow.com?SAMLart=. Note that the protocol has changed to the secure https instead of http. The user is redirected now to Site 2's SAML service, which examines the URL with the appended information. Based on the information in the URL, Site 2's SAML service communicates with Site 1's, and Site 1 sends along the authenticated identity of the user, along with any rights that the user has.
Step 4 the user is sent to Site 2, fully authenticated. The user can now perform transactions on the site just as if he had logged directly into the site.
The future of SAML
SAML is not yet a fully accepted standard. OASIS, the consortium that develops XML standards, is expected to accept the first official SAML standard this summer or late spring. Sometime in the fall, you can expect products to be available that can make use of the accepted spec.As with all standards, though, expect some problems. It's unclear whether a Web service built using an early version of SAML will be able to completely work with a Web service built using a later version. Considering that SAML 1.0 hasn't even been accepted yet, it's a moot point right now, but could be problematic in the future.A bigger potential issue is whether Microsoft will buy in to the spec. Even though Microsoft is an OASIS board member, it's working on its own separate authentication protocols, known as WS Security and WS License. If Microsoft decides to continue work on them and use them as an alternate to SAML, all bets are off as to how useful the protocol will prove in the long run.
AD and LDAP
Active Directory is a database based system that provides authentication, directory, policy, and other services in a Windows environment
LDAP (Lightweight Directory Access Protocol) is an application protocol for querying and modifying items in directory service providers like Active Directory, which supports a form of LDAP.
Short answer: AD is a directory services database, and LDAP is one of the protocols you can use to talk to it
Active directory is a directory service provider, where you can add new user to a directory, remove or modify, specify privilages, assign policy etc. Its just like a phone directory where every person have a unique contact number. Every thing in AD(Active Directory) are considered as Objects and every object is given a Unique ID.(similar to a unique contact number in a phone directory.
Ldap is a protocol specially designed for directory service providers. Windows server OS uses AD as a directory server, AIX which is a linux version of IBM uses Tivoli directory server. Both of them uses LDAP protocol for interacting with directory.
Apart from protocol there are LDAP servers, LDAP browsers too.
reference: http://searchsoa.techtarget.com
Federation:
Federation describes scenarios in which no group or organization manages all users and resources in a distributed application environment. Instead, administrators in diverse domains must manage local security policies that support mutually beneficial transactions among their respective spheres of operation. In the world of distributed network services, the term refers to the need for trust agreements among decentralized security and policy domains. Federation lets access-management functions span diverse organizations, business units, sites, platforms, products and applications. Federation requires that an organization trust each trading partner to authenticate its own users' identities. In a federated environment, a user can log on to his home domain and access resources transparently in external domains, such as those managed by customers or suppliers, subject to various policies defined by home and external administrators.Federation used with a new security standard, the XML-based Security Assertions Markup Language (SAML). The standard defines XML/Simple Object Access Protocol-based protocol interactions that support real-time authentication and authorization across federated Web services environments. The standard defines request and response messages that security domains use to exchange authentication, attribute and authorization information in the form of trust-assertion messages about named users and resources. Users log on to their home domains through authentication techniques such as ID/password or Kerberos, and this authentication is communicated to a federated destination site through a SAML authentication assertion.
How SAML works
One of the most important of those security issues is user authentication - specifically, allowing a user to sign on or use multiple Web services from separate but affiliated sites, without having to authenticate himself at every step of the process. That's the job of SAML (Security Assertion Markup Language), an XML-based standard for authentication and authorization that provides a "single sign-on" so that people can be authenticated once and then be able to access multiple Web services. SAML allows each individual site to have its own mechanism for sign-on and authentication, but will allow sites to accept authenticated users from other sites.
Why SAML is needed
Before we take a look at how SAML works, let's take a look at why it's needed. Let's say someone visits an airline site with a Web services architecture, and reserves tickets after signing on and being authorized to buy the tickets. The site offers special deals with partner sites on hotel stays and car rentals, and so the user decides to make reservations with them. In order to make reservations with each of those partner sites without SAML, the person will have to sign on separately to each site, using different user names, passwords and authentication information. He also might have to enter special codes that say he is entitled to the special deals. But with SAML, the person would only have to sign on to the first site, and he would then automatically be authenticated via SAML at the affiliated sites.Even more problematic are complex B2B transactions done via Web services. Web services will most likely be used in automated transactions that involve multiple business partners, including manufacturers, distributors, packagers, suppliers and retailers. With no way to authenticate each partner and what they can and can't do in a transaction, these transactions won't be able to be done automatically. With SAML handling authentication, complex transactions can be automated without worrying about authentication problems.
SAML Implementation
So how does SAML tackle all this? At its base, SAML is nothing more than a series of XML-based messages that detail whether users are authenticated, what kind of rights, roles and access they have and how they can use data and resources based on those rights and roles. It will work with HTTP, SMTP, FTP and SOAP, among other protocols and technologies.
The three main components of the SAML specification are:
Assertions SAML has three kinds of assertions:
1. Authentication assertions are those in which the user has proven his identity.
2. Attribute assertions contain specific information about the user, such as his spending limits.
3. Authorization decision assertions identify what the user can do, for example, whether he can buy an item.
Protocol:
This defines the way that SAML asks for and gets assertions, for example, using SOAP over HTTP for now, although using other methods in the future.
Binding: This details exactly how SAML message exchanges are mapped into SOAP exchanges.
The assertions are exchanged among sites and services using the protocol and binding - and those assertions are what authenticates users among sites.
SAML in real life
How does SAML work in real life? Let's take a real-life example. Say someone logs in and uses a Web service, is authenticated and then wants to go to a partner site. With SAML, he can be authenticated at the second site without having to sign on. The nearby figure shows each step of the process:
Step 1 the user has authenticated himself with Site 1 and wants to visit Site 2. He clicks on a link to go to Site 2.In
Step 2, instead of being sent straight to Site 2, he is instead sent to the SAML service for Site 1.
Step 3 the SAML service appends a partner ID and a special handle to Site 2's URL in the user's browser.
For example, if the user wants to go to the site http://www.buymenow.com, after the SAML service appends the extra information, the URL might now be https://www.buymenow.com?SAMLart=. Note that the protocol has changed to the secure https instead of http. The user is redirected now to Site 2's SAML service, which examines the URL with the appended information. Based on the information in the URL, Site 2's SAML service communicates with Site 1's, and Site 1 sends along the authenticated identity of the user, along with any rights that the user has.
Step 4 the user is sent to Site 2, fully authenticated. The user can now perform transactions on the site just as if he had logged directly into the site.
The future of SAML
SAML is not yet a fully accepted standard. OASIS, the consortium that develops XML standards, is expected to accept the first official SAML standard this summer or late spring. Sometime in the fall, you can expect products to be available that can make use of the accepted spec.As with all standards, though, expect some problems. It's unclear whether a Web service built using an early version of SAML will be able to completely work with a Web service built using a later version. Considering that SAML 1.0 hasn't even been accepted yet, it's a moot point right now, but could be problematic in the future.A bigger potential issue is whether Microsoft will buy in to the spec. Even though Microsoft is an OASIS board member, it's working on its own separate authentication protocols, known as WS Security and WS License. If Microsoft decides to continue work on them and use them as an alternate to SAML, all bets are off as to how useful the protocol will prove in the long run.
AD and LDAP
Active Directory is a database based system that provides authentication, directory, policy, and other services in a Windows environment
LDAP (Lightweight Directory Access Protocol) is an application protocol for querying and modifying items in directory service providers like Active Directory, which supports a form of LDAP.
Short answer: AD is a directory services database, and LDAP is one of the protocols you can use to talk to it
Active directory is a directory service provider, where you can add new user to a directory, remove or modify, specify privilages, assign policy etc. Its just like a phone directory where every person have a unique contact number. Every thing in AD(Active Directory) are considered as Objects and every object is given a Unique ID.(similar to a unique contact number in a phone directory.
Ldap is a protocol specially designed for directory service providers. Windows server OS uses AD as a directory server, AIX which is a linux version of IBM uses Tivoli directory server. Both of them uses LDAP protocol for interacting with directory.
Apart from protocol there are LDAP servers, LDAP browsers too.
reference: http://searchsoa.techtarget.com
