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

[Anil Saldhana]

We do include a bunch of federation servlets that provides same 
functionality on a servlet container (not necessarily Wildfly/EAP).
On Wildfly/EAP, we recommend use of the authenticators/valves.

On 06/27/2013 10:58 AM, Anil Saldhana wrote:
> There is an handler stack at both the SP and IDP. It depends on what
> handlers are configured.
> The set of handlers are here:
> https://docs.jboss.org/author/display/PLINK/SAML2+Handlers
> The source is at
> https://github.com/picketlink2/federation/tree/master/picketlink-core/src/main/java/org/picketlink/identity/federation/web/handlers/saml2
>
> The idea is that SPs redirect to IDP for user authentication. The IDP
> will return SAML assertion about the subject (user), itself (issuer),
> authentication mode used
> and optionally include roles of the user. You can turn off the roles
> being sent from the IDP but by default we send it.  The SP can take the
> SAML assertion and
> can take the roles sent by the IDP , augment them or build it own. The
> handler framework gives us the flexibility to do a lot of things -
> roles, encryption,signature
> and other things.
>
> Configuration happens in picketlink.xml (or management console /
> picketlink subsystem).
>
> On 06/27/2013 10:36 AM, Bill Burke wrote:
>> Ok, apologies.  Last time I looked at your SAML stuff it didn't support
>> roles and was implemented as a servlet filter.
>>
>> On 6/27/2013 11:27 AM, Anil Saldhana wrote:
>>> * SAML tokens can contain information about the subject, issuer,
>>> authentication, authorization decisions and attributes (that can be
>>> roles). It is just a rich XML token.
>>> * PicketLink SAML stuff is deeply integrated with Wildfly App Server via
>>> the JBossWeb authenticators/valves.  We have not looked at Undertow yet.
>>>
>>> On 06/27/2013 10:23 AM, Bill Burke wrote:
>>>> I don't think the SAML token includes role information.  Also, I don't
>>>> believe the Picketlink SAML stuff is integrated with the app server,
>>>> correct?  meaning you can't get integrated Java EE security.
>>>>
>>>> On 6/27/2013 11:15 AM, Anil Saldhana wrote:
>>>>> Eric,  semantics is close to the SAML OAuth2 Bearer Token Profile.
>>>>> http://tools.ietf.org/id/draft-ietf-oauth-saml2-bearer-16.txt
>>>>>
>>>>> Maybe in the future there may be opportunities to replace SAML SSO in GWT UI
>>>>> by lightweight JSON based SSO probably involving JSON Web Token (JWT).
>>>>>
>>>>> On 06/27/2013 06:59 AM, Eric Wittmann wrote:
>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>