Soffit Connector Data Model

[Drew Wills]

Folks,

Some updates, and a request for input…

Quickly — I created brief, elevator-style summary of the soffit concept in a new slide deck:  https://docs.google.com/presentation/d/1Sml4MzbNuS-1D-brZiXzrI3wQlf9IYtyZmp_E_8NtM4/edit?usp=sharing

Andrew Stuart recently demonstrated the need to flesh out the model for what information is sent by the SoffitConnector, in JSON, to the remote soffit endpoint…

  - https://github.com/Jasig/uPortal/pull/665#issuecomment-225335281

and also offered some help in filling that out…

  - https://github.com/drewwills/Soffit/pull/3

The current version of that POJO — SoffitRequest — is just a stub.  There was a plan to review the information we have, and make a reasonably comprehensive/generous plan to share it with the remote endpoint.  I’ve written up a draft of that now…

  - https://github.com/drewwills/Soffit/wiki/Soffit-Connector-Data-Model

Some questions:

  - (1) Have I overlooked anything you can think of?

  - (2) I threw everything I could find into this model on the theory that someone might need it;  is there anything listed that we _shouldn’t_ send, due to security risk?  (FYI ultimately I hope to have a UI accessible from the Portlet Manager that would allow you to opt in/out of sending some elements of the data.)

  - (3) I haven’t (yet) added a place for a Jason Web Token (JWT);  am I correct that the JWT is something we need to send in this transmission?

  - (4) What about items with a type of Map<String,Object>?  I’m thinking I probably should omit them because of issues deserializing them in the target JVM.

I hope to allow this draft to mature a bit through discussion.  Soon, however, I want to convert it to .java files in the repo (where we can continue to discuss it and mature it).

drew

[Misagh Moayyed]

Chiming in a bit:

 

2) Disallow support for HTTP endpoints, or make it option that is on by default.

3) No, you do not need it. In fact, I’d advise against it. Maybe this is an optional thing, but not the default. *

4) Don’t think there are any issues with it. Depends what Object is. If you limit it to primitives and a few collection types, you should be fine.

 

* This could have made more sense if you had something hyper sensitive in the payload, and you seriously wanted the receivers of the JWT to be authenticated. Don’t think you do. 2 should help some.

[Drew Wills]

On Jun 15, 2016, at 8:41 AM, Misagh Moayyed <mmoa...@unicon.net> wrote:

Chiming in a bit:

Please do… thanks very much!

2) Disallow support for HTTP endpoints, or make it option that is on by default.

Ah yes… I had some thought along these lines.

+1 for option to disallow non-SSL connections, and even for making that the default.  I would, however, like to preserve the ability to use HTTP in development.

What about something like…

  - (1) SSL required by default, though you can manually (change config) disable this requirement

  - (2) If you do, generate a WARNing in the log for each request serviced

  - (3) non-secure connections from localhost, however, are always allowed

3) No, you do not need it. In fact, I’d advise against it. Maybe this is an optional thing, but not the default. *

We very well could have sensitive things in the payload on the level of PII.  I believe (and hope) this model actively discourages more sensitive items (such as database passwords) from being a part of that, since the soffit payload is essentially for generating the markup that goes to the browser.  (You are free to use some of the soffit payload in generating markup for the browser.)  Actual application data comes from REST APIs.  Those should be fully-configured in deployment.

4) Don’t think there are any issues with it. Depends what Object is. If you limit it to primitives and a few collection types, you should be fine. 

Ah but I’d have to maintain code that inspects these collections and makes judgments about what can be serialized and what can’t.  It sounds like a messy business.

drew

[Andrew Stuart]

+1 on HTTPS by default.

(3)

For JWT, the primary reason I'd advocate for including it JWT signing and validation.

Presumably, since these backend services will likely be exposing JSON REST services as the primary interface (the exception being returning some bootstrap code via Soffit), the same JWT will be presented by clients consuming the REST services. Since they can trivially validate the JWT signature, it creates a standardized way of validating ID assertions and that they're coming from uPortal. I think it's important that they come from uPortal since 99% of the time, uPortal will have to augment any claims it gets externally with the internal portal roles, attributes, etc.

Providing the JWT to the service as part of the initial request means that even from the very bootstrap request (though not only there) we can deny access to portlets that ought not to be accessed by certain roles. Whether that's failing with `403 Forbidden` or providing a neutral generic interface for less-privileged roles, I like the idea of user information being handled in a standardized way.

Encryption would be nice, but I'd agree with Misagh (if I understand him correctly) that it's probably more trouble than it's worth. Any sensitive data should probably just be retrieved directly from uPortal (by querying portal with JWT, which validates the token and signature again) over HTTPS.

Since I mentioned it, and now that I'm thinking about using a standardized method, I think my recommendation would be:

• Provide the JWT in the Authorization header as a bearer token

This would be the expected behavior for accessing the JSON services, so why not keep it simple and use the same header for the bootstrap (soffit) endpoint?  It obviously makes using your platform's security framework (I'm thinking of Spring Security) a lot simpler if it's the same across all endpoints.

(4)

The #1 reason I would still recommend map<String, Object> is that it handles JSON type serialization properly, which *vastly* decreases complexity over the landscape of possible soffit services. There are lots of nice libraries for deserializing JSON for a given language, and the implementation is language-specific, and developers should be able to expect that a number will be a number in that language, and that they only need to assert that (however their language would require they do so).

If we only allow string values (e.g.), that inevitably leads to every consumer doing lots of string->number parsing (or, *shudder*, putting nested JSON in strings). I'd say that JSON is so popular because of its flexibility, and we ought to make sure that we work with that rather than limit it and cause headaches and workarounds for everyone.

Andrew Stuart

---

From: "Andrew Wills" <awi...@unicon.net>
To: "Misagh Moayyed" <mmoa...@unicon.net>
Cc: "uPortal Developers" <uport...@apereo.org>
Sent: Wednesday, June 15, 2016 9:28:33 AM
Subject: Re: [uportal-dev] RE: Soffit Connector Data Model

--
You received this message because you are subscribed to the Google Groups "uPortal Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uportal-dev...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/uportal-dev/.

[Drew Wills]

Andrew et al.,

On Jun 15, 2016, at 10:31 AM, Andrew Stuart <ast...@unicon.net> wrote:

  - (4) What about items with a type of Map<String,Object>?  I’m thinking I probably should omit them because of issues deserializing them in the target JVM.

The #1 reason I would still recommend map<String, Object> is that it handles JSON type serialization properly, which *vastly* decreases complexity over the landscape of possible soffit services. There are lots of nice libraries for deserializing JSON for a given language, and the implementation is language-specific, and developers should be able to expect that a number will be a number in that language, and that they only need to assert that (however their language would require they do so).

If we only allow string values (e.g.), that inevitably leads to every consumer doing lots of string->number parsing (or, *shudder*, putting nested JSON in strings). I'd say that JSON is so popular because of its flexibility, and we ought to make sure that we work with that rather than limit it and cause headaches and workarounds for everyone.

I think maybe we’re talking about different things on this item.

I’m looking at methods like PortletRequest.getAttribute() — http://portals.apache.org/pluto/portlet-2.0-apidocs/javax/portlet/PortletRequest.html#getAttribute(java.lang.String) — which returns an Object.  WRT what could be in there, the javadocs say only “In a distributed portlet web application the Object needs to be serializable."

I’m concerned that…

  - (1) There may be objects in there of Java classes that don’t support JSON serialization/deserialization well;  and

  - (2) There may be objects in there of Java classes that aren’t in the remote JVM at all, and therefore can’t be deserialized there

I feel that — at a minimum — we need to limit the contents of the soffit payload to…

  - (a) Things in JDK 8

  - (b) Things in the soffit jar

  - (c) Dependencies of the soffit jar

And I think it’s probably best to go just a bit further, and limit it to a & b only.  I don’t think it hurts us — I think we’re primarily interested in Strings, Dates, numeric types… not much else.

drew

[Benito J. Gonzalez]

Right, I say keep it to a curated set of data -- no need to throw in "the kitchen sink". Might need to unroll some objects, but it's the data we care about as opposed to object representations.

Going back to JWT, I would say add it (as a header) but also share the claims in the body for those apps that don't want to fuss with it. Those apps avoidng JWT can blindly trust data in the request, hit an API endpoint in uPortal, or use some other way to validate claims. This potentially saves one or more network calls during initiation.

Just my $.02
-bjagg

--
You received this message because you are subscribed to the Google Groups "uPortal Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uportal-dev...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/uportal-dev/.

-- 
Benito J. Gonzalez
Software Developer
Unicon, Inc.
Voice:  480.558.2360
 Text:  209.777.2754
Email:  bgon...@unicon.net
GitHub:  bjagg
BitBucket:  bjagg

[Andrew Stuart]

Yeah, that makes sense; I ran into an issue with Jackson serializing a Vector playing with straight serialization of the Principal (or at least whatever concrete type we're using for CCC), so I can understand wanting to make sure that doesn't happen. 

I've posted a few of my thoughts as issues on the core Soffit repo as proposals, mostly centered around pivoting the Soffit abstraction to include the original HTTP request, portlet-specific decorations, and user assertions as explicitly separate entities, which should hopefully allow maximum flexibility and enable new-to-portal developers to reason more easily about what they're seeing.

--

Andrew Stuart

[Andrew Petro]

Apologies for the delay in chiming in on this.

> (1) Have I overlooked anything you can think of? ... I threw everything I could find into this model on the theory that someone might need it; 

I recommend a different lens. Is there anything in this data model that could be removed or deferred? YAGNI. Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher.

I get the wanting to get it complete out of the gate, release it, run with it without having to cut another release or change it. I do. But I'd trade that away to gain a more iterative, evolutionary approach to growing the product. Add to the data model when a Soffit integration for real needs specific additional data elements to accomplish something for a real adopter in production. This is a way to stave off complexity and feature creep, to focus on the highest value features.

Towards that end, reviewing the Soffit Connector Data Model page:

Can the portlet concepts go?

• Window states and portlet modes seem clunky. Can we do without them, or at least defer projecting forward this JSR-ism?
• Window IDs. Things get way simpler, we've found in MyUW, if we don't have these. Lead with not needing them and see if anything terrible happens. Multiple windowing of a single portlet-definition adds a lot of complexity, maybe without enough benefit for that complexity.
• It's got: init parameters, context attributes, container runtime options. Could that be slimmed down out of the gate?
• Session attributes seem weird. Soffit is remoting the portlet back end. And the session is a back-end thing. So can the session simply live in the back end and not be passed over the wire?
• Rather than leading with roles being part of the Soffit data model, suggest leading with *not* doing this and making back ends responsible for figuring out and applying roles. Back ends could do this in all sorts of ways. It might turn out that the portal needs to be figuring this out for the back end, but I don't think that architecture is a given.
• Differentiating Name and Title might have been a mistake. This is a chance to try collapse these to a single concept.
• What's a Namespace and how do we avoid needing to have it? :)

Should some of this be happening at the HTTP header layer?

In general, part of what happened with Servlets was turning HTTP data into Java objects. And then Portlets were like, whoa, what if we didn't even have those Servlet Java objects. So stuff was stuffed into the Java object model that was "really" happening at the http layer, it's just the Portlet didn't so much have direct access to that, because Abstraction.  But hey! With Soffit, there's an opportunity to get back to benefiting from HTTP.

• ETAG should be happening at the layer of HTTP headers rather than in the payload, shouldn't it?
• AuthType? Seems meta. Convey it as a HTTP header if at all?
•  Locales stuff, could that be HTTP headers? Accept-Language? 
• Preferred content type, content type negotiation more generally, http has got headers for this.
• Secure in the portlet world was about whether the portal was rendering via http or https.  In a LetsEncrypt world, is this flag needed? Likewise Scheme. It'll always be http or https, and either way should deal with that at a layer above the Soffit data model. :)

Other refactoring:

• This is an opportunity to clarify the units on duration elements right in their names. So, TimeoutSeconds rather than Timeout and MaxInactiveIntervalSeconds rather than just MaxInactiveInterval.
• Maybe that wiki page would be better as a Markdown file in the repo itself, so it can be updated transactionally with the code it documents. And is amenable to pull requests. :)

> (2) on security risk

Yeah. There's some different kinds of risk.

One risk is that some of this data would be sensitive and would be sent unnecessarily. The mythical Social Security Number user attribute. Ability to filter what user attributes are conveyed to which soffits, or to not send them at all and rely on the back end to look up its own user data thanks, might eventually be needed.  Probably okay to ignore this problem out of the gate to avoid adding complexity.

Another risk is getting confused about where what authentication and what user role validation is happening how.

Where in the architecture is user authorization to do the thing they're doing verified, how much? Is the Soffit client providing coarse grained authorization and preventing unauthorized users from exercising the wrong soffits? Is the back end expected to validate user authorization, roles?

How does the back end know that the request came from the portal? Noting that it'd be a fine thing (and largely preferable in bootstrapping) to stipulate that this authentication is happening at a transport layer above the Soffit payload abstraction layer, but gotta say it clearly so that adopters know that that authentication, authorization needs to be happening at that layer.

> (4) What about items with a type of Map<String,Object>?  I’m thinking I probably should omit

Please omit. Serializing objects is a pain. Would be at least an interesting experiment to see if can avoid this pain. Soffit remotes the back end, so maybe a front end isn't adding a lot of value figuring out how to stuff characteristics of the request into Java objects when if they came from the end user they're natively String request parameters already on the request and if they didn't come from the end user then where the heck did they come from and maybe Soffit just doesn't need them, or has already sufficiently modeled them elsewhere in the data model.

Request parameters only, and then see if in the doing it turns out something really really really needs an Object.

Again, maybe some of this complexity comes back later as need is demonstrated. But man oh man, I'd hate to project forward the foibles of JSR Portlets unnecessarily.

Kind regards,

Andrew

[Drew Wills]

Terrific feedback.  I’d also say it lines up pretty well — for the most part -- with the things Andrew Stewart & I have been discussing (on the few occasions we’ve had some time).

More below...

On Jul 14, 2016, at 6:21 AM, Andrew Petro <andrew...@wisc.edu> wrote:

Apologies for the delay in chiming in on this.

> (1) Have I overlooked anything you can think of? ... I threw everything I could find into this model on the theory that someone might need it; 

I recommend a different lens. Is there anything in this data model that could be removed or deferred? YAGNI. Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher.

I get the wanting to get it complete out of the gate, release it, run with it without having to cut another release or change it. I do. But I'd trade that away to gain a more iterative, evolutionary approach to growing the product. Add to the data model when a Soffit integration for real needs specific additional data elements to accomplish something for a real adopter in production. This is a way to stave off complexity and feature creep, to focus on the highest value features.

Yes, this is exactly the tension.  My sense is that updating/documenting/releasing the data model will be too slow & difficult to do it frequently — that an individual soffit effort will not be able to leverage that process within the constraints of its budget & due date.  So yes — I think we should we should prepare a data model with _legs_.

But I’m thinking of succeeding at that by changing the design philosophy of the Payload object and sub-structures away from strongly-typed fields, toward weakly-typed attributes.  This change will simultaneously allow us to reduce what we’re sending for now (until we learn we need it) and add more elements in the future without having to change the Payload object. It’s the same approach we’ve used in other things — like the Notification portlet.

Towards that end, reviewing the Soffit Connector Data Model page:

Can the portlet concepts go?

• Window states and portlet modes seem clunky. Can we do without them, or at least defer projecting forward this JSR-ism?

I wrestle with this one.  On the one hand, I can envision the system of modes+windowStates adding value;  on the other, I can see a value in removing the complexity (not that it’s terribly complex) and allowing the few soffits that need it simply to manage it internally.

I think I see more value in windowStates than in modes.  WindowState (if offered) is a consideration that concerns the module & the container jointly.

• Window IDs. Things get way simpler, we've found in MyUW, if we don't have these. Lead with not needing them and see if anything terrible happens. Multiple windowing of a single portlet-definition adds a lot of complexity, maybe without enough benefit for that complexity.

Sounds reasonable, especially given the expandable/weakly-typed approach outlined above.

• It's got: init parameters, context attributes, container runtime options. Could that be slimmed down out of the gate?

Almost certainly.  In particular initParametrs seem pointless — they’ll (probably) be identical for all soffits. 

• Session attributes seem weird. Soffit is remoting the portlet back end. And the session is a back-end thing. So can the session simply live in the back end and not be passed over the wire?

These are gone (already).  All substructures of type Object were removed from the plan.  Just updated the page.

• Rather than leading with roles being part of the Soffit data model, suggest leading with *not* doing this and making back ends responsible for figuring out and applying roles. Back ends could do this in all sorts of ways. It might turn out that the portal needs to be figuring this out for the back end, but I don't think that architecture is a given.

I feel like I have a good handle on this topic, but it’s a bit wordy to explain… 

I both agree & disagree.

User Roles On Campus (e.g. 'Student'):  Best of the soffit interacts with the Identity system to learn these.  And this approach is what we fully expect.  The part of the soffit that returns markup mostly doesn’t need to know these — that’s a matter for the REST APIs that the Soffit markup interacts with.  These will (probably… often) use Spring Security and something like shib.

Group Affiliations in uPortal (e.g. ‘Desktop Device Access’ or ‘Portal Administrator’ or ‘Announcements Editors'):  These can easily be intra-portal constructs exclusively.  I would like to pass uPortal groups for this reason.  Perhaps it should be renamed from ‘Roles’ to ‘Groups.’

• Differentiating Name and Title might have been a mistake. This is a chance to try collapse these to a single concept.

Good point — I’m open to this idea.

• What's a Namespace and how do we avoid needing to have it? :)

I don’t see how we avoid needing to have it.  This is (probably) the item on the top of my list for strongly-typed, POJO-level support.

The namespace is how we create selectors we use to unleash out Javascript upon the DOM.  They can also be used in CSS.

Should some of this be happening at the HTTP header layer?

Very possibly.

(I’ve run out of time — more later.)

drew

[Pascal Rigaux]

Hi,

Looking at Soffit, I like the Web widget orientation :)

I have a question:

Since payload is signed & encrypted, could the initial request on
https://soffit-foo/
be done from the browser (Ajax) instead of being proxied by uportal
Soffit connector?

Consequences:
- for the end user, it means the soffit would be async. It also means
more requests in the browser.
- if https://soffit-foo/ is down, it would not break anything else,
no need to tune timeout in Soffit connector
- "/" request on https://soffit-foo/ need to handle CORS

WYT? Am i missing something?

cu

[Drew Wills]

Pascal,

I can’t remember all the details just now, but I remember that previously I have had some trouble doing things like…

<script>
$(function() {
// some javascript initialization work here
});
</script>

within HTML that is injected into the page with AJAX.

One thing we are stressing heavily with Soffit best practices is the idea that the initial HTML (proxied but the portal) should be static or near-static. It should be instantaneous, and _potentially_ even cached across users (in future).

On no account should a Soffit, in constructing the initial HTML, reach out to a data source and render (for example) a table or lit that is pre-filled with data.

drew

[Pascal Rigaux]

Hi,

Drew Wills <awi...@unicon.net> a écrit :

> I can’t remember all the details just now, but I remember that
> previously I have had some trouble doing things like…

> [...]

> within HTML that is injected into the page with AJAX.

jQuery.html has some tricks to handle this
(http://stackoverflow.com/a/1197585)
Quite ugly, but not a big deal either.

> One thing we are stressing heavily with Soffit best practices is the
> idea that the initial HTML (proxied but the portal) should be static
> or near-static. It should be instantaneous, and _potentially_ even
> cached across users (in future).

In that case, if requested directly by the browser, it would also be
cached (great).

But that was my next question:
If the initial HTML be mostly static, how do you handle soffit api requests?
- https://github.com/drewwills/soffit-samples API is public
- https://github.com/andrewstuart/soffit-go-poc initial HTML contains
a hand-created JWT,
used in soffit-go-poc API

[Pascal Rigaux]

Pascal Rigaux <Pascal...@univ-paris1.fr> a écrit :

> [...]
> If the initial HTML is mostly static, how do you handle soffit API requests?

Hum, maybe I misunderstood and all requests to Soffit client are
proxied through uportal?

[Drew Wills]

On Nov 9, 2016, at 12:08 PM, Pascal Rigaux <Pascal...@univ-paris1.fr> wrote:

But that was my next question:
If the initial HTML be mostly static, how do you handle soffit api requests?

Here’s an example of “mostly static” HTML in a Soffit…

  - https://github.com/drewwills/soffit-samples/blob/master/src/main/webapp/WEB-INF/soffit/health-check/view.jsp

The only non-static element is the namespace — ${portalRequest.attributes['namespace'][0]}.

In this case…

  - It’s very fast to generate

  - Can be cached in the portal

But!…

  - Cannot be cached across users

drew

[Drew Wills]

On Nov 9, 2016, at 12:50 PM, Pascal Rigaux <Pascal...@univ-paris1.fr> wrote:

Hum, maybe I misunderstood and all requests to Soffit client are proxied through uportal?

The Soffit samples I have include RESTful JSON APIs. (2 of 3 do.)

The HTML in these Soffits is hitting those APIs directly — not through the portal.  These examples use JSONP to make that work.

But we don’t have to do it that way always.  We could provide an API-proxy in the portal.  I believe UW has something like that.

drew

[Andrew Petro]

> We could provide an API-proxy in the portal.  I believe UW has something like that.

And you too can have it. :)

https://github.com/UW-Madison-DoIT/rest-proxy

[Drew Wills]

Sounds great.  I would like to explore “bundling” this component with uPortal 5.

(NOTE:  I put that word in quotes because I’m not sure we know what bundling looks like in uPortal 5.)

drew

[Pascal Rigaux]

But i don't think rest-proxy can be used to add the various X-Soffit-*
headers : you need uportal session for this ?!


For the record, my "soffit" would be something like:

uportal constructs this html:

<div class="soffit" data-fname="soffit-foo">
...
<script> soffits = { "soffit-foo": { "url": "https://soffit-foo/",
payload: { .... } } }; </script>
<script src="load-soffits.js"></script>

where load-soffits.js is:

$(".soffit").each(function() {
var elt = $(this);
var soffit = soffits[elt.attr("data-fname")];
$.ajax(soffit.url, { headers: soffit.payload }).then(function (html) {
window.soffit_payload = soffit.payload;
elt.after(html);
});
});

the mostly static html code https://soffit-foo/ would init the widget
using window.soffit_payload, saving it in some local vars.


- the container (uportal) just need to compute the JWTs payload
- Soffit clients should use CORS (unless hosted on same vhost)
- Soffit clients are mostly standard web widgets



Andrew Petro <andrew...@wisc.edu> a écrit :

>> We could provide an API-proxy in the portal. I believe UW has something
> like that.
>
> And you too can have it. :)
>
> https://github.com/UW-Madison-DoIT/rest-proxy
>
> On Wednesday, November 9, 2016 at 1:58:45 PM UTC-6, awills wrote:
>>
>>
>> On Nov 9, 2016, at 12:50 PM, Pascal Rigaux <Pascal...@univ-paris1.fr

>> <javascript:>> wrote:
>>
>> Hum, maybe I misunderstood and all requests to Soffit client are proxied
>> through uportal?
>>
>>
>> The Soffit samples I have include RESTful JSON APIs. (2 of 3 do.)
>>
>> The HTML in these Soffits is hitting those APIs directly — not through the
>> portal. These examples use JSONP to make that work.
>>
>> But we don’t have to do it that way always. We could provide an API-proxy
>> in the portal. I believe UW has something like that.
>>
>> drew
>>
>

[Drew Wills]

The thing is — if I understand this approach correctly — you don’t really need to go through this controller for that…

  - https://github.com/drewwills/Soffit/blob/master/src/main/java/org/apereo/portal/soffit/renderer/SoffitRendererController.java#L93

You can provide a (servlet spec) controller that maps to that request and returns an HTML fragment on your own terms.

The Soffit approach is for expressly designed to be a contract for portal/pluggable-content-widget communication.

drew

[Pascal Rigaux]

Hi,

In ESUP-Portail (France), we've been looking at how we could
standardize our needs around JWTs.
Here are a few resulting thoughts:

- standardize on OpenID Connect claims
(http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims)
when possible

- standardize on verifying JWT signature using a "jwks_uri"
(
https://github.com/auth0/node-jwks-rsa/tree/master/examples/express-demo
https://bitbucket.org/b_c/jose4j/wiki/JWT%20Examples#markdown-header-using-an-https-jwks-endpoint http://openid.net/specs/openid-connect-core-1_0.html#RotateSigKeys
)

- WIP : see if CAS with cas-server-support-oidc can generate JWTs that
can be passed to an API


Looking at the differences with current Soffit implementation:

- soffit has symmetric key signature & encryption [*]
In OIDC, clients wanting encryption provide their public key on registration
And public keys for verifying signature are provided by jwks_uri.

- org.apereo.portal.soffit.model.v1_0.Bearer has "username"
"attributes" claims.
One could try mapping attrs to standard OIDC claims.
https://wiki.refeds.org/display/GROUPS/Mapping+SAML+attributes+to+OIDC+Claims


NB: OpenID Connect is going to be used more in more in France (cf
https://fr.wikipedia.org/wiki/FranceConnect, only french for now...)


[*] Is encryption needed in case the JWT is sent back to the browser?

--
Pascal Rigaux

[Brandon Powell]

Hi,

I will try to answer your questions inline:

- standardize on OpenID Connect claims (http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) when possible

 

The RFC for JWT have a list of claims that can be used (https://tools.ietf.org/html/rfc7519#section-4.1) I think we should use those first, before going with anything else. But if something doesn't fit from the JWT RFC, I don't mind using the OpenID Connect claims. I would not however send ALL the information in the OpenID Connect claims on every request. That is a lot of data being pushed over the wire.  

- standardize on verifying JWT signature using a "jwks_uri"
  ( https://github.com/auth0/node-jwks-rsa/tree/master/examples/express-demo https://bitbucket.org/b_c/jose4j/wiki/JWT%20Examples#markdown-header-using-an-https-jwks-endpoint http://openid.net/specs/openid-connect-core-1_0.html#RotateSigKeys )

This looks really interesting. This looks like a better way of providing security, but it does add a lot more complexity. That is another service to setup, secure and maintain. I don't mind that being an option. We should focus right now on getting out a minimum viable product. 

- WIP : see if CAS with cas-server-support-oidc can generate JWTs that can be passed to an API

 

Oakland is moving away from CAS to Shibboleth right now. Granted we still are technically using CAS, but the CAS protocol inside of Shibboleth. While this might be useful to some, I don't think it is a good idea for uPortal to rely completely on it for Soffits to work

[*] Is encryption needed in case the JWT is sent back to the browser?

I would say yes, encryption is needed when the JWT is sent to the browser. With an unencrypted JWT a user can go to jwt.io and see all the data inside the token. Granted they cannot modify it because the validation would fail. In our case we are passing some values that we would not want to the user to actually see. For example we pass around a unique database identifier; a user cannot do anything with that number, but I'd like it if they never see it.   

If you have any other questions about JWTs let me know and I can try to answer them for you.

Thanks,

Brandon

[Drew Wills]

Pascal,

I’m sorry — I had your email set aside for replying, but we’re having a busy week before the holidays.

Some responses below...

> On Dec 12, 2016, at 1:41 PM, Pascal Rigaux <pascal...@UNIV-PARIS1.FR> wrote:
> - standardize on OpenID Connect claims (http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) when possible

A couple things…
- We use JWTs for more things than user data
- But as far as user data, you should be able to use that standard if you want to

That’s because the JWT that represents the user simply contains whatever attributes you define in personDirectory.

If you want those attributes in the JWT, you only need to define them.

A couple more things…
- There should be a method for whitelisting/blacklisting attributes, but we don’t have it yet
- Possibly there could be a method for mapping portal attributes to different names, but this item might be a step too far

> - standardize on verifying JWT signature using a "jwks_uri"
> ( https://github.com/auth0/node-jwks-rsa/tree/master/examples/express-demo https://bitbucket.org/b_c/jose4j/wiki/JWT%20Examples#markdown-header-using-an-https-jwks-endpoint http://openid.net/specs/openid-connect-core-1_0.html#RotateSigKeys )
>
> - WIP : see if CAS with cas-server-support-oidc can generate JWTs that can be passed to an API
>
>
> Looking at the differences with current Soffit implementation:
>
> - soffit has symmetric key signature & encryption [*]
> In OIDC, clients wanting encryption provide their public key on registration
> And public keys for verifying signature are provided by jwks_uri.
>
> - org.apereo.portal.soffit.model.v1_0.Bearer has "username" "attributes" claims.
> One could try mapping attrs to standard OIDC claims. https://wiki.refeds.org/display/GROUPS/Mapping+SAML+attributes+to+OIDC+Claims
>
>
> NB: OpenID Connect is going to be used more in more in France (cf https://fr.wikipedia.org/wiki/FranceConnect, only french for now...)
>
>
> [*] Is encryption needed in case the JWT is sent back to the browser?

Yes, exactly.

We expect Soffit HTML to invoke Servlet-based REST APIs. Securing those APIs with the portal-provided JWT is not required; they are offered as a convenience.

It’s not too late to look at securing the JWT with jwks_uri, if that’s the right way to go.

drew


>
> --
> Pascal Rigaux