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-commo... 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/0808a9916093af60... 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

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-commo... >> >> 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/0808a9916093af60... >> >> 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/security-dev >> > _______________________________________________ > security-dev mailing list > security-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev >

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-commo... >>>> >>>> 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/0808a9916093af60... >>>> >>>> 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

* 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-commo... >>>>>> >>>>>> 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/0808a9916093af60... >>>>>> >>>>>> 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

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... 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-commo... >>>>>>>> >>>>>>>> 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/0808a9916093af60... >>>>>>>> >>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>>