[security-dev] PicketLink Usecase: SAML/GWT/REST Authentication

Eric Wittmann eric.wittmann at redhat.com
Thu Jun 27 07:59:21 EDT 2013


Right - I think OAuth2 is likely the proper way to go about solving 
this.  The only reason I didn't go down that road was that I wanted to 
align with the version of picketlink included in EAP.  In a future 
version of Overlord (next product cycle) I'm guessing we'll switch from 
SAML to OAuth2.  Assuming the proper functionality is available out of 
the box in whatever version of EAP is available at that time.

-Eric

On 06/26/2013 04:42 PM, Bill Burke wrote:
> Resteasy has already implemented something like this, but not SAML based:
>
> http://docs.jboss.org/resteasy/docs/3.0.1.Final/userguide/html/oauth2.html
>
> On 6/26/2013 2:45 PM, Eric Wittmann wrote:
>> Everyone,
>>
>> I'll just add a few more details to (hopefully) help add context.
>>
>> We have multiple UI applications in the Overlord world, and we wanted
>> them all to be secured using SSO.  PicketLink/SAML worked very well to
>> accomplish this, and it was trivial to get all of the UI WARs protected.
>>
>> Once the GWT apps themselves are protected, the browser can make RPC
>> calls to the originating context for free, and the servlets being
>> invoked will have a JAAS authenticated user.
>>
>> The last piece is then making REST calls to some *other* web context on
>> behalf of the JAAS user.  The REST services might be hosted in some
>> other context on the same server or even on some other server.
>>
>> So the approach is to issue a SAML token that contains the principal and
>> all its roles, then pass that in an HTTP header when invoking the remote
>> REST services.  The REST services are protected by two login modules - a
>> standard BASIC auth login module and another one that can consume a SAML
>> token.
>>
>> There is a vital piece still missing, which is to actually sign the SAML
>> token when sending, and verifying the signature when consuming.  If
>> anyone would like to help with that it'd be super helpful!  :)
>>
>> Lastly - I'm certainly not a security expert, and am happy to be shown a
>> better way to solve this use case going forward (note: we needed to use
>> the version of picketlink that comes with EAP 6.1 - fwiw).
>>
>> -Eric
>>
>>
>> On 06/26/2013 02:18 PM, Anil Saldhana wrote:
>>> Hi All,
>>>       this is a use case solved by Eric Wittman of Project Overlord using
>>> PicketLink.
>>>
>>> Final Solution in Eric's words:
>>> Use-case is:  GWT UI app is protected by SAML SSO.  The UI makes GWT RPC
>>> calls back to itself.  The UI RPC servlets (server-side) then make REST
>>> calls to a set of REST services hosted in another web application, using
>>> SAML tokens for authentication.
>>>
>>> JIRA: https://issues.jboss.org/browse/DTGOV-11
>>>
>>> Background:
>>> Eric had gotten his GWT UI App to use SAML SSO using PicketLink. He was
>>> looking for ways to now make calls from the GWT app to REST services on
>>> RESTEasy without re-authentication.He needed to get this usecase working
>>> with PicketLink and RESTEasy bundled in EAP6. During discussions and
>>> future plan, it was decided to use OAuth for REST services and look at
>>> SAML Bearer Token Profile for guidance.
>>>
>>> Solution:
>>> Since RESTEasy authentication can use JAAS authentication,  Eric wrote a
>>> login module for SAML bearer tokens.
>>> https://github.com/Governance/overlord-commons/blob/master/overlord-commons-auth/src/main/java/org/overlord/commons/auth/jboss7/SAMLBearerTokenLoginModule.java
>>>
>>> I created a JIRA issue in PicketLink to migrate this login module:
>>> https://issues.jboss.org/browse/PLINK-165
>>>
>>> This login module will be available in PicketLink v2.5.0
>>> https://github.com/anilsaldhana/picketlink-bindings/blob/0808a9916093af6095430447e6899172fe19e86a/picketlink-jbas-common/src/main/java/org/picketlink/trust/jbossws/jaas/SAMLBearerTokenLoginModule.java
>>>
>>> I wanted to open a thread for discussion on this. I am unsure if other
>>> projects have similar needs but this use case is pretty awesome to share
>>> here.
>>>
>>> Regards,
>>> Anil
>>> _______________________________________________
>>> security-dev mailing list
>>> security-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/security-dev
>>>
>> _______________________________________________
>> security-dev mailing list
>> security-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/security-dev
>>
>


More information about the security-dev mailing list