Does SAML-auth data management app make sense?

[alechenninger]

@jewzaam brought this up today, and this has come up before. Basically, if any deployment of data management is SAML enabled, it doesn't necessarily matter because anyone can download the app and point it at lightblue with CORS enabled.

It would only make sense if lightblue services only had a certain allowed origin set, then the data management app would only be useful from particular hosts that it was served, and that means not all app deployments are equal (if you just downloaded it and deployed it yourself, that origin would not be allowed.) Therefore, in that case, that the app is SAML enabled becomes significant. However, you can still just hit the service yourself, and because the app is just a lightblue-specific frontend for CURL basically, I think it doesn't make sense for the app to be more or less restrictive than CURL would be on your machine.

Therefore, I think it makes sense to get rid of the saml enabled data management application.

If the apps were merged though, would metadata management make sense to follow the same pattern? You would have to have a cert to use metadata management, too, for instance.

[jewzaam]

If the metadata mgmt app followed the same pattern as data mgmt app it would be OK. Though there is the question of how to determine what dropdowns to present in the UI. If it's no longer in the saml assertion the app would need to fetch groups from ldap.. not a nice thing.

Given that saml wouldn't require you to actually log in, we could keep saml when merged.

[alechenninger]

Would it make sense that to have a service API, given some authentication info (be it cert, basic auth, whatever), return the roles that lightblue attributes to your user? Then SAML would not be necessary. The app talking to whatever lightblue instance via CORS would expose UI appropriate based on analysis of whatever lightblue says your roles are.

If metadata mgmt app used CORS like data app, I think this might be the only way really? Because even if you use SAML, you can point to any lightblue service you want directly. For example, what does the SAML assertion have to do with my random lightblue host I might spin up on openshift?

[jewzaam]

But since you can deploy the app anywhere and change the code, you could just have something that says you're authorized to do any metadata operations. A simple option would be show every operation in the UI with a marker, maybe asterisk, that indicates you can only use it if the backend says you're authorized. The data management app doesn't indicate in the UI what you can or cannot do. It's complicated given authorization will be dependent on what you're querying or changing. Ultimately for both apps it's what the backend lightblue services say is allowed that matters and we could look at keeping both front end apps simple/dumb.

[alechenninger]

Yeah, I was thinking very rough analysis by the application, not very fine grained. Doesn't metadata management have predefined roles? For instance, if you don't have write permissions to ANY entities, you could rule out the create/update bits.

I agree not totally necessary as the data management app has demonstrated but, I was under the impression that metadata permissions were simpler to analyze.

[jewzaam]

Deciding if a user has permissions to any entities would be a problem for data mgmt today. There's no authz info in the cert. We happen to keep it in LDAP, but it could change based on who is using lightblue. It's possible a service endpoint could be created to expose that data generically. Kind of think we might need that for another potential "dumb" client use case so that UI can make decisions on what to render based on the user's roles. Data mgmt app wouldn't even need to know the principal. Just has to make an authenticated request to the "give me a list of my roles" service endpoint.

[jewzaam]

Though, it is not quite that simple. The HttpRequest allows lightblue code to check if the request has a role in it. I don't believe you can get a list of the roles.