Time |
S |
Nick |
Message |
00:38 |
|
|
HighBit joined #rest |
00:41 |
|
|
shrink0r_ joined #rest |
03:49 |
|
|
lemur joined #rest |
06:12 |
|
|
ewalti joined #rest |
06:59 |
|
|
scflode joined #rest |
06:59 |
|
|
scflode joined #rest |
08:19 |
|
|
ewalti joined #rest |
08:29 |
|
|
_ollie joined #rest |
08:50 |
|
|
ewalti joined #rest |
08:55 |
|
|
quimrstorres joined #rest |
09:03 |
|
|
quimrstorres joined #rest |
10:00 |
|
|
scflode joined #rest |
10:06 |
|
|
rosstuck joined #rest |
10:33 |
|
|
scflode joined #rest |
11:09 |
|
|
Left_Turn joined #rest |
11:18 |
|
|
quimrstorres joined #rest |
11:54 |
|
|
quimrstorres joined #rest |
12:28 |
|
|
CentaurWarchief joined #rest |
12:30 |
|
|
_ollie joined #rest |
12:52 |
|
|
scflode joined #rest |
12:58 |
|
|
shrink0r joined #rest |
13:54 |
|
|
scflode joined #rest |
13:54 |
|
|
quimrstorres joined #rest |
13:55 |
|
|
_ollie joined #rest |
13:55 |
|
|
ekroon joined #rest |
13:55 |
|
|
dkm joined #rest |
13:55 |
|
|
Guest18878 joined #rest |
13:56 |
|
|
HighBit joined #rest |
13:56 |
|
|
fumanchu_ joined #rest |
13:56 |
|
|
asm89 joined #rest |
13:56 |
|
|
prologic joined #rest |
13:56 |
|
|
EnergyCoffee joined #rest |
13:57 |
|
|
saml joined #rest |
13:58 |
|
|
CentaurWarchief joined #rest |
13:58 |
|
|
Left_Turn joined #rest |
13:58 |
|
|
Davey joined #rest |
13:58 |
|
|
StatelessCat joined #rest |
13:58 |
|
|
asdf` joined #rest |
13:58 |
|
|
blahdeblah joined #rest |
13:58 |
|
|
StatelessCat joined #rest |
14:01 |
|
|
saml joined #rest |
14:01 |
|
|
saml joined #rest |
14:23 |
|
|
nkoza joined #rest |
14:55 |
|
|
scflode joined #rest |
15:51 |
|
|
quimrstorres joined #rest |
15:57 |
|
jackalista |
Thanks wartung and pdurbin. yeah, XACML is a little complex, as usual, you pay for the abstraction somehow |
15:58 |
|
jackalista |
so what is better if you need fine grained authorization for data? |
15:58 |
|
trygvis |
seems like most people are away on easter vacation |
15:58 |
|
jackalista |
lol |
15:58 |
|
jackalista |
I just got back |
15:58 |
|
jackalista |
:) |
15:59 |
|
trygvis |
I handle all authentication/authorization stuff with "normal" security within the application |
16:00 |
|
trygvis |
at work we use spring security or just simple shared users/passwords in nginx |
16:00 |
|
trygvis |
the former for stuff used by clients, the latter for internal stuff or testing |
16:00 |
|
trygvis |
but we also only have a single application |
16:01 |
|
trygvis |
well, single deployment. it's getting so big that it can be drawn up as different apps |
16:03 |
|
pdurbin |
trygvis: your "normal" security is hand rolled within the app, sounds like |
16:03 |
|
pdurbin |
or maybe you're saying you use Spring Security |
16:04 |
|
trygvis |
yes, spring security for authentication and hibernate listeners to check that the current user has access to the object being loaded |
16:04 |
|
trygvis |
that covers 95% of the normal cases, there is always some special stuff for signup and stuff |
16:10 |
|
pdurbin |
ok. I should try Spring Security I guess. |
16:12 |
|
trygvis |
I don't know if you want to use that unless you're already on the spring wagon |
16:13 |
|
trygvis |
if you want something more generic I think this is pretty good: http://shiro.apache.org/ |
16:13 |
|
trygvis |
I haven't used it myself, but heard plenty of good stuff about it from good people |
16:21 |
|
jackalista |
spring security is good shit fotr a single web app |
16:21 |
|
jackalista |
i have used it many times |
16:21 |
|
jackalista |
but we are looking at api mgmt platforms |
16:21 |
|
pdurbin |
jackalista: even if I'm not on the Spring bandwagon? |
16:21 |
|
jackalista |
and I am looking at how to move as muchg as possible onto these pltforms |
16:21 |
|
jackalista |
well, spring sec is a *very* good impl |
16:21 |
|
jackalista |
better than jaas by a lonbg shot, IMO |
16:22 |
|
jackalista |
and it can be used outside of a sppring app |
16:22 |
|
jackalista |
but you should have a reason to go to the trouble, if not in spring |
16:22 |
|
jackalista |
you know? |
16:22 |
|
jackalista |
don't make life difficult for yourself for no reason I mean |
16:22 |
|
pdurbin |
well, it's some trouble to write you own auth |
16:23 |
|
jackalista |
so anyway, I'm looking for what the future holds in fine grained authz |
16:23 |
|
jackalista |
and seeing how much can be moved out of the service endpoints |
16:23 |
|
jackalista |
it's too hard to manage and over see that way |
16:23 |
|
jackalista |
too hard to audit |
16:23 |
|
jackalista |
I'm in a financial services firm |
16:23 |
|
|
lemur joined #rest |
16:23 |
|
jackalista |
audit is best friend |
16:23 |
|
jackalista |
all tx's must be auditable! |
16:24 |
|
jackalista |
yes, what we want to do is saay to our clients that we use XYZ best of breed tools, ABC best practices, etc. |
16:24 |
|
jackalista |
not "trust me, we rolled our own"!, lol |
16:25 |
|
jackalista |
not that we couldn't but in our industry, we shouldn't |
16:25 |
|
trygvis |
to be honest, externalizing security like that is a recipe for a total clusterfuck |
16:25 |
|
jackalista |
I'[m finding that some platforms, say akana/soa software uses stuff like ws-policy... I was surprised to see that |
16:25 |
|
trygvis |
if you're thinking of placing some kind of generic stuff in front of your apps |
16:26 |
|
jackalista |
well, you wpould rather have hundreds of services with endpoint based security? |
16:26 |
|
jackalista |
at the very least, identity needs to be centralized |
16:26 |
|
jackalista |
authz is harder to say |
16:27 |
|
pdurbin |
trygvis: do you consider using Shiro a case of externalizing security? |
16:27 |
|
trygvis |
no, that would still run inside the application and be configured with the application |
16:27 |
|
pdurbin |
ok. phew :) |
16:28 |
|
trygvis |
jackalista: authentication can be externalized, and you could probably gain from doing so |
16:29 |
|
jackalista |
authn will definitely be cedntrailziedc and excternalk |
16:29 |
|
jackalista |
centralized and external |
16:29 |
|
jackalista |
lol |
16:29 |
|
trygvis |
when I worked in finance the network/ops people deployed apache/big ip in front to take care of load balancing, ssl termination, client certificate checks (where applicable), IP-based access control (where application) |
16:29 |
|
trygvis |
that combination worked quite good |
16:30 |
|
trygvis |
they could also have some basic filtering of allowed methods to certain paths, so if some apps where totally read-only they could allow just GET and HEAD |
16:30 |
|
jackalista |
we have something similar, but are looking at what to do for fine grained access control. we have some interesting needs along those lines. this goes beyond what a BIG IP can get you, it's more like entitlment mgmt |
16:31 |
|
trygvis |
that shop was a java shop, so we had some jar files with 'useful security stuff', stuff like servlet filters that could be configured |
16:32 |
|
trygvis |
but every app has its own requirements and domain model so it just doesn't make sense to make something central checking. to me at least :) |
16:32 |
|
jackalista |
trygvis: yeah, the api mgmt platforms have a pretty good story for that via oauth and scopes, can easily associate scopes that allow for one role just a GET but for another, a PUT, POST or DELETE |
16:32 |
|
trygvis |
having a central registry of "stuff a client has access to" is probably useful, like client "abc" can "transfer money" |
16:34 |
|
jackalista |
yeah, that's correct, and we are trying to take a closer look. not just xfrer $, but so and so can xfter $ for this client and that project/account/etc |
16:35 |
|
jackalista |
at first blush xacml looks pretty good, but not enough adoption |
16:35 |
|
|
quimrsto_ joined #rest |
16:35 |
|
jackalista |
is shiro usefulk for this sort of stuff, or is it j7ust for usualy web app sort of stuff? |
16:35 |
|
trygvis |
well, I wouldn't even try to make it generic |
16:36 |
|
trygvis |
shiro is the same kind of stuff as spring security. just not "tied" to spring |
16:36 |
|
trygvis |
probably a bit more low level |
16:36 |
|
jackalista |
does it integrate with things like OAuth2 nicely? |
16:36 |
|
trygvis |
dunno, haven't used it myself |
16:37 |
|
jackalista |
ah, k, thx anyway |
16:37 |
|
jackalista |
we have needs for RBAC and ABAC and would like to tie both to data, essentially, in the most forward looking way possible |
16:37 |
|
jackalista |
not clear just yet what that is |
16:38 |
|
jackalista |
was surprised to see a vendor using ws-policy, and not sure that is the right way to go, at leaqst for us |
16:40 |
|
trygvis |
I just don't see the need for extra stuff to support it |
16:41 |
|
trygvis |
is this thing going to be a filter in front of your app or something your app queries per request? |
16:41 |
|
jackalista |
well, we have a semi large number of apps, and will have an even larger number of services feeding those apps |
16:42 |
|
jackalista |
yes, it's a means of presenting an API front compoent of sorts |
16:42 |
|
jackalista |
all API traffic goes over it |
16:43 |
|
whartung |
jackalista: fine grain security is, and always will be, a pain. There's simply no way around it. Best practices don't actaull really even "help" here. |
16:44 |
|
jackalista |
lol |
16:44 |
|
jackalista |
yeah, I've been feelin' that |
16:44 |
|
jackalista |
in that light, xacml doesn't look so bad! :P |
16:45 |
|
jackalista |
still not sure about ws-policy tho, shit |
16:45 |
|
whartung |
because the simple truth is, that "security" need not be more "complicated" than "isUserInRole(xxx)". But that hides SO much complexity, it's not even funny. |
16:47 |
|
trygvis |
yes, and then you could define credit limits as a business thing and stick it in your application. yay! |
16:47 |
|
jackalista |
lol |
16:48 |
|
jackalista |
that's not really our problem. imagine we have a half million contract workers that today, get access to XYZ enterprise and ABC of their projects |
16:48 |
|
jackalista |
imagine that one can work for > 1 enterprise concurrently, but can'ty share info across them |
16:49 |
|
jackalista |
we have basic role based problem space but need to tighten with attributes |
16:49 |
|
* fumanchu_ |
hands one of them a usb stick |
16:49 |
|
jackalista |
they aren't rteally invested too much in that sort of thing |
16:49 |
|
whartung |
now, see, you can express your rights as "role and attributes". JEE just has "roles", because any menagerie of "roles and attributes" can be flattened in to a single role namespace. |
16:50 |
|
jackalista |
but we need to keep our end tight, we can't control what we can't control, etc. |
16:50 |
|
jackalista |
yes but it's more efficient with roles and attr's, otherwise you get a shitload of roles |
16:51 |
|
jackalista |
not any eqasier from an adm9in perspective |
16:51 |
|
whartung |
the other problem is that most apps focus on access to VIEWS rather than so much access to DATA. |
16:51 |
|
jackalista |
API stuff here |
16:51 |
|
jackalista |
apps will also have app level sec |
16:51 |
|
jackalista |
but tjhey're all fgeediong from services |
16:51 |
|
jackalista |
feeding |
16:53 |
|
|
tieTYT2 joined #rest |
16:53 |
|
whartung |
the task is how to project all of your criteria, and then how to manage all that criteria. In the end, each invdividual user has a potentually unique set of rights. |
16:53 |
|
jackalista |
a role in an app will also haver a corresponnding oauth token wityh similar authz |
16:53 |
|
jackalista |
exactly |
16:53 |
|
jackalista |
how most effeciently |
16:53 |
|
jackalista |
efficiently |
16:53 |
|
jackalista |
dang |
16:55 |
|
whartung |
and what you'll find is that the more detail that you check for, the more detail you have to manage. Beacuse it all comes down to bits of information. The simplest system has 1 bit: can or can't access. As you add bits (roles, rights, attributes), the problem geometrically explodes. |
16:55 |
|
jackalista |
what also makes this interesting is that th3ese 500,000 contract workers have temporary access to what data they can access |
16:55 |
|
whartung |
yay -- time windows |
16:55 |
|
whartung |
those are fun too |
16:55 |
|
jackalista |
yep |
16:55 |
|
whartung |
UTC, of course. |
16:56 |
|
jackalista |
people get rolled on and off of projects, so access follows that, nothing too tricky |
16:56 |
|
whartung |
"Well,…uhmmm… see they work 9 to 5 PDT but we're on the east coast, and is it DST their now? Math is hard." |
16:56 |
|
|
quimrstorres joined #rest |
16:59 |
|
jackalista |
the tool I need would say that for project ABC for company XYZ, let so and so *view* the data about stuff that wqs brought, etc., or let them *edit* the bought stuff to add an item, etc. |
17:00 |
|
whartung |
yea, and see here's the rub. |
17:00 |
|
whartung |
Nobody has that tool |
17:00 |
|
jackalista |
if u imagined that these were spoftware contractors, that's close enough for rock and roll |
17:00 |
|
whartung |
because at that level, everyone like to manage this stuff their own way |
17:01 |
|
jackalista |
haha |
17:01 |
|
whartung |
they think "how hard can this be" |
17:01 |
|
jackalista |
yeah, well, if true, we will soon :) |
17:01 |
|
jackalista |
it's hard |
17:01 |
|
jackalista |
I already know that |
17:01 |
|
whartung |
they find that they can abstract 80% of the bits |
17:01 |
|
jackalista |
rtry8ing to keep our investment in tool making minimal here :) |
17:01 |
|
whartung |
in to groups, departments, applications, whatever. |
17:01 |
|
jackalista |
the api mgmt platforms are not bad dude, 80% already abstracted |
17:01 |
|
whartung |
but you still have to manage all of the bits. |
17:02 |
|
whartung |
it's the 20% that kills you |
17:02 |
|
jackalista |
80% done for me for the most part |
17:02 |
|
jackalista |
exactly on the 20% |
17:02 |
|
jackalista |
that's why the questions |
17:03 |
|
whartung |
well the answer is, there is no answer. |
17:03 |
|
whartung |
the 20% is where the rubber meets the road |
17:03 |
|
whartung |
and where folks diverge |
17:03 |
|
whartung |
so -- that 20% is on you. |
17:03 |
|
jackalista |
yeah, just wondering what you guys had seen, used, etc. |
17:03 |
|
jackalista |
been here before, many times |
17:03 |
|
jackalista |
the tools ever change and the questions stay the same :) |
17:04 |
|
whartung |
I've done this several times, it always sucks |
17:04 |
|
whartung |
no magic bullet here |
17:04 |
|
jackalista |
no magic needed, but some things will have better legs than others |
17:05 |
|
|
mezod joined #rest |
17:05 |
|
whartung |
yea, there you go deluding yourself again |
17:06 |
|
whartung |
some things may have better legs FOR YOU, but that's remote. It's a universal problem without a unviversal solution. |
17:06 |
|
jackalista |
well, of courtse, I'm not doing it for you ;) |
17:13 |
|
jackalista |
agree, no magic soln here. for the context of the place I work, there are some solutions that will be better than others, as is nearly always the case, considering context |
17:14 |
|
jackalista |
that's what makes this shit fun, dude! |
17:16 |
|
|
quimrsto_ joined #rest |
17:37 |
|
|
quimrstorres joined #rest |
18:00 |
|
|
quimrstorres joined #rest |
18:24 |
|
|
jcromartie joined #rest |
18:40 |
|
|
quimrstorres joined #rest |
18:41 |
|
|
quimrstorres joined #rest |
19:31 |
|
|
quimrstorres joined #rest |
19:49 |
|
|
quimrstorres joined #rest |
19:52 |
|
|
shrink0r joined #rest |
20:24 |
|
|
shrink0r_ joined #rest |
20:26 |
|
|
shrink0r joined #rest |
20:28 |
|
|
shrink0r_ joined #rest |
20:34 |
|
|
tieTYT2 joined #rest |
21:49 |
|
|
zama joined #rest |
22:02 |
|
|
fumanchu joined #rest |
22:16 |
|
|
quimrstorres joined #rest |
23:13 |
|
|
huckleberry78 joined #rest |