PicketLink Architectures

In this article, I will go over the various architectures possible with PicketLink.

Architecture Type 1: (SAML Web Browser Profile Based)

 

You have a centralized identity provider that provides seamless SSO into your web based applications.

 

 

SAMLSSOArchitecture.png

 

 

 

The Identity Provider can not only make decisions about authentication but also can act as the source of attributes/access control.  SAML2 allows the encapsulation of authorization decisions as Authorization Statements to be passed to the services.

Architecture Type 2: (WS-Trust STS Based Architecture)

 

Here the trust anchor of your trusted system is the PicketLink Security Token Server (STS).

 

 

PicketLinkSTSArchitecture.png

 

Services running on the various containers such as JBoss AS, Tomcat etc can make PicketLink STS calls to get security tokens issued. These tokens can be based on SAML assertions or can be custom proprietory ones.  This security token can then be used to make calls into the other containers. At the other end, the service after receiving this security token will in turn validate the token with the STS. This is the case of trusted security propagation

 

 

https://www.jboss.org/dms/picketlink/images/picketlink_banner.png