SAML SSO with Shibboleth

Original Source – SAML SSO with Shibboleth

How does SAML work? IdP’s & SP’s

SAML, or Security Assertion Markup Language, is the leading SSO protocol today and is a valuable standard to understand in order to fully comprehend how SAML active directory single sign on works.

SAML boils down to attribute exchange through the creation of trust relationships between IdP’s and SP’s. A basic example is signing into your active directory to log on to your work computer in the morning, and automatically gaining access to your company gmail or salesforce.

The three main components of the SAML protocol:

Assertions – Most common are the following 2 SAML assertions:
Authentication assertions are used to make people prove their identities.
Attribute assertions are used to generate specific information about the person, for example their phone number or email address.
Protocol – This defines the way that SAML asks for and gets assertions, for example, using SOAP over HTTP.
Binding – This details exactly how SAML message exchanges are mapped into SOAP exchanges.

5 Benefits of using a SAML IdP:

There are many reasons to use a SAML IdP. Besides being the dominant single sign on protocol in use today, there are a host of reasons an organization should consider implementing a SAML IdP. Here are 5 reasons to use SAML for SSO:

1. User passwords never cross the firewall, since user authentication occurs inside of the firewall and multiple Web application passwords are no longer required.

2. Web applications with no passwords are virtually impossible to hack, as the user must authenticate against an enterprise-class IdM first, which can include strong authentication mechanisms.

3. “SP-initiated” two factor security provides access to Web apps for users outside of the firewall. If an outside user requests access to a Web application, the SP can automatically redirect the user to an authentication portal located at the Identity Provider. After authenticating, the user is granted access to the application, while their login and password remains locked safely inside the firewall.

4. Centralized federation provides a single point of Web application access, control and auditing, which has security, risk and compliance benefits.

5. A properly executed identity federation layer that satisfies all of the use cases described above and supports multiple protocols can provide an enterprise-wide, architecturally sound Internet SSO solution.

OpenID Connect Lesson of the Day: Discovery & Transient ID’s

After being stumped by a client’s OpenID Connect question earlier today, we wanted to dig deeper for some answers.

We turned to the knowledgeable and helpful OpenID Connect Spec Gurus for clarification and the following is what we learned…

Our Query to the Oracles of OpenID Connect:

“As I understand OpenID Connect discovery, a person would specify username@host…

Could the user simply enter “@host” instead?

Its not a valid address, but for discovery, it could be sufficient. Perhaps this would facilitate the return of a non-correlatable (transient…) identifier by the OP to the RP, which could help protect the privacy of the person.”

Response from OpenID Gurus:

Yes, according to the discovery docs you can enter just the host/domain name (without the @ sign) and Webfinger will still work. You can also enter the issuer URL directly. Both of these allow for directed-identifier use cases, where you know the IdP but don’t know the end user at runtime, and this is a key feature for OIDC.

What does this all mean?

It means that a user can retain 100% privacy when web access management products. Many organizations do not want RP’s to be able to track a specific person. If a different identifier is released to each RP, the user can act more anonymously on the Internet. If the user is causing trouble at the RP (like trying to hack the RP…), the IDP can still track down the person who was issued the “transient” identifier in question. In many cases, the RP really doesn’t need to know which specific user at the domain is requesting the content–frequently the RP just needs to know that the person is licensed or authorized

The above scenario is widely in use by universities using the Shibboleth support for transient ids. A similar approach is also used by some vendors to minimize the release of attributes to websites.

 

Guest Blog: IDaaS – Verifying the ID ecosystem operational posture

Many companies find themselves unable to respond to the emerging ID security threats because of a lack of awareness and maturity in their organization. Identity as a Service (IDaaS) benefits are appealing — enabling organizations to bridge that knowledge gap more quickly. In addition to improved security, IDaaS services can reduce IT costs, enable new services and align IT with best practices [1]. However, the use of IDaaS has not been widespread, sometimes simply because companies don’t really understand the cloud identity offerings that exist.

The IDaaS Maturity Framework

IT staff should ask for the following crucial questions:

IdM/IAM : What is the IdM/IAM maturity level of my organization?

OA Maturity : Centralized authentication and shibboleth sso are an important part of a service oriented architecture.
Identity Ecosystem : To what extend should the solution support Internet standards.
ID in the Cloud : How “cloudy” is the solution.

A new metric has been developed [2] to define the level of confidence organizations might verify before moving ID to the Cloud. However, looking at the above IDaaS maturity framework, here we want to focus on how organization can mitigate the risks of ecosystem security posture when they decide to implement their own IDaaS model as a consequence of the appraised IdM/IAM and SOA maturity levels.

Use Case: Mapping IDaaS to the ID Ecosystem Posture

Supposing an IdM/IAM maturity level and a SOA grade and governance applied through the organization can be identified and measured:

IdM/IAM maturity: automated maturity level [1];

SOA maturity: systematic maturity level (see Fig. 2) [1].

Then an IDaaS model [1] might be defined to move the ID to the Cloud: which IDaaS model could satisfy the organization ID maturity and compliance with respect to the ID ecosystem posture?

Here is a practical way to verify the Providers/Participants ecosystem framework federation compliance (vet Federated Sso, standard policies and procedures, schema definition, authentication mechanisms, authorization scopes) and the continuous contribution of autonomous partners. Looking at the figure above, consider the following steps:

Value of the organization IdM/IAM maturity level. This value sets the organization confidence in terms of designing authentication and authorization, directory integration service together with the requirements to meet accesses (UMA, OAuth …), performance, availability, compliance, business continuity. Supposing the IdM/IAM maturity level is 40% (Policy based reporting and auditing [1]), the organization could subscribe an Hybrid IDaaS model;

Value of the organization SOA maturity level. Supposing the SOA grade of maturity is 30% (Systematic: there exists partnership between technology and business organizations in order to assure that the use of SOA provides clear business responsiveness [1]), the ID Hybrid service might be possible but it should be tested. A scalable multi-parted federated stack [4] maps the ecosystem and so participants to the framework(s) can be accessed and navigated. At this stage, data and credentials should be kept at their locations, both on-premise and in the Cloud;

Applying the IDaaS model: does the operational test satisfy the designed ID Hybrid service? If yes, an IDaaS Hybrid contract can be temporary subscribed, although under verification. During the IDaas model proof time, the service should be monitored to meet expectations. If no, then 2 options should be analyzed to:
understand why the operation/mapping is not what expected by design and testing:
– What is the gap between the test outcome and the expectations?
– Does the gap depend upon providers and participants mapping compliance?
– What is the severity of any mismatches detected in the framework(s)?
– Could the gap be covered through limited efforts and costs?
Evaluate the lower ID Provider Hosted IDaaS model.

In any case, the ID in the Cloud scenario appears clear and under control. The scalable multi-parted federated stack plays a crucial role [4]: the way to define the appropriate IDaaS model is unambiguous. Above all, there is awareness in moving ID to the Cloud. Effort, costs and outcomes are measurable and the terms of the IDaaS subscription (the ID clauses in the Cloud contract) can be based upon operational test results and, eventually, operational monitoring. Still, the ID ecosystem framework itself can be classified depending upon participants (and providers) reliability.

Conclusion

The ID ecosystem framework is a critical step in moving ID to the Cloud. Once the organization is aware of his IdM/IAM and SOA maturity then this is time to understand how to mitigate risks and optimize costs in externalizing ID [3]. Verify the ID ecosystem operative posture is a must and it can be accomplished using open sources multi-party federated stack. Still, outcomes are crucial in setting the contract clauses of the IDaaS subscription.