Tuesday, January 25, 2011

IdP initiated SAML2 SSO in webLogic - Passing data from IdP to SP

Pushing custom attributes in Custom AttributeStatement (part of SAML assertion, see OASIS SAML2 specification for details), from WebLogic based Identity Provider (IdP) towards a Service Provider (SP) isis not possible in weblogic 10.3.3-). This effectively means that we will not be able to transfer additional user information (for instance email address or some token number) in the form of custom SAML2 attributes in SAML assertion.

Here I describe a workaround where-in we will be able to pass data (that ideally should be in the form of AttributeStatement that goes in the SAML assertion generated at IdP end) from WebLogic IdP towards any SP in IdP initiated SSO.

If we want to send across any information from IdP end to SP end, what we can do is embed that information into the form which is used to hit the initiator servlet. This information should be available through hidden field. Take following JSP page into consideration (in consistent with discussion at Configuring WebLogic IdP initiated SAML2 based SSO ):

<h2>Services Available</h2>



<form method="post" action="http://localhost:27001/saml2/idp/sso/initiator">

<br>Service -1 (at localhost:37001/appB)<br>

<input type="hidden" name="SPName" value="sp1"/>

<input type="hidden" name="RequestURL" value="http://localhost:37001/appB/admin/services.jsp"/>

<input type="hidden" name="acnum" value="<%=session.getAttribute("acnum")%>"/>

<input type="submit" value="submit"/>





- IdP is running at localhost:27001
- SP is running at localhost:37001

The initiator servlet will get hold of the additional request attribute ("acnum" in above example) and append it to the relayState parameter as a querry parameter. When the post form posts the relay state to ACS, ACS will consume the assertion, get hold of the target URL (=relayState) and redirect the browser to it. Once we land on this URL, all we need is to get the parameter as a normal request parameter (in SP application), like:

The implications of this workaround are:
  1. the additional data will be sent as a query parameter (and not in the response assertion).
  2. HTTP Redirect Binding has to be used instead of post
  3. even if the assertion or response is signed, it will have no effect on query string.

No comments:

Post a Comment