Had a great time this week at ApacheCon. This talk was presented on Thursday…
I’ve been mentoring a graduating senior in computer science. Here’s what I told him…
First, read the 10 steps to becoming the developer everyone wants. It contains some pretty good strategies for what to do after you’ve landed that first job, how to become indispensable.
But even if you get that first job straight away, it’s never too early to start building a public reputation. If you’re not already a member, join the social media outlets like linkedin, twitter, and the like. Where you can collaborate over concepts and ideas. Linkedin has some pretty good groups to join. Once you become fluent in a topic, you can start your own group. For example, here’s one that I manage: Linkedin Open Source IAM group.
Even more important, open a github account and start publishing work there. Read about The impact github is having on your software career.
Also be sure to join tech groups in your hometown. These will put you in the same room with like-minded professionals. Here’s one that I’ve recently joined: Little Rock JUG.
Then publish articles about topics that interest you. If they interest you they will likely interest others. Write about the research that you have completed. Yes, the nitty-gritty details. People love technical details when well thought out. Retweet articles (written by others) that you like or agree with. Follow people that have work that you admire rather than for personal (friendship) reasons. If you see something you like, let the other person know, ask questions about it. If you see something you disagree with, offer constructive criticisms. Above all be respectful and positive in your communications with others. This is healthy collaboration in action and will be an important part of your technical career, as it blossoms.
Forget about being the genius capable of writing superb software all by yourself. That genius is a unicorn, at most 1% of the population. If that’s you (and I don’t think that it is) congratulations and carry on! You won’t need any more of my advice. Otherwise, if like 99% of the population (the rest of us), you absorb knowledge by working around others. Surround yourself with the smartest people you can find. Be humble. Admit that you don’t understand how it works yet. Keep your mouth (mostly) shut until you’ve learned from the people who came before, the current experts. They will respect you for that and will encourage your ideas as they become viable. Later, once you’ve mastered the basics, you may tell them how to improve, and they will listen.
Eventually, perhaps after many years (less if you are lucky), you’ll have earned a good public reputation, and with it, a large number of loyal followers. These people will then help you communicate about software projects that you’re interested in. The latest releases of your software, conferences that you’re speaking at, articles that you’ve written, etc…
Afterwards you need not worry about finding a job again. They will find you. A public reputation supersedes any single organizational boundary and gives you complete control over your career’s path.
ApacheCon is just a couple months away — coming up May 16-18 in Miami. We asked Shawn McKinney, Software Architect at Symas Corporation, to share some details about his talk at ApacheCon. His presentation — “The Anatomy of a Secure Web Application Using Java EE, Spring Security, and Apache Fortress” will focus on an end-to-end application security architecture for an Apache Wicket Web app running in Tomcat. McKinney explains more in this interview.
Project Link: Apache Fortress Demo Project
1. A couple of rowdy roles were ejected but returned the next day.
“Just who do they think they are?” asked the doorman.
“They rbac”, said the bartender.
2. Some random attributes wandered into the local bar and the bartender said,
“We don’t allow your kind around here.” The attributes were taken abac.
3. An RBAC permission walks into the bar and the bartender says,
“I thought I told you earlier to stay out of here.” The perm replies,
“You can’t deny my access.”
4. A hierarchical role walks into a bar. Bartender says,
“Hey, I know both of your parents so you best behave yourself.” And the role replied,
“Oh yeah, which ones?”
5. A group of wild attributes arrived onto the scene, stirring trouble, when the bartender said.
“You attrs better watch out, the roles rbac in town”.
6. A role and a permission walk into the bar and bartender asks,
“What’ll you have?”
“We’re celebrating a new relationship, may we please have a round?”, one asked politely.
“I’ll grant that”, replied the bartender.
7. An obviously ecstatic user strides into the bar, pulls out a huge wad of cash and buys everyone in the house a drink.
“Where’d you get all that dough?” asked the bartender.
“I’m on a role”, was the reply.
8. Two roles, in an adulterous relationship, obviously ill at ease, whispered to each other as they sat at the bar.
“What’s wrong with you two?”, the bartender asks.
“You look constrained”.
9. Two roles got into a heated political argument and a visibly annoyed bartender asks them,
“Hey, am I going to have to separate you two?”
“Don’t you be giving us static!”, one of them replied.
10. An obviously drunk role’s behavior grew increasingly unruly as the night wore on.
“Get the hell outta here!” the bartender yells at him. Afterwards the role became inactive.
11. An ABAC permission’s wallet was stolen while sitting at the bar and asks for help.
“Who had access to you while you were here?”, the bartender asks.
“I have no idea”, the perm replied.
12. An abac attribute suddenly appeared and the bartender said,
“We don’t serve your kind here.”
“Why not?”, the attribute asked.
“Because there’s no telling where you came from”, said the bartender.
For years I’ve been on record proclaiming that identity centralization is good and synchronization is bad. I reasoned it is better to re-engineer processes to share identities than to distribute and fragment them.
I still believe this to be true. However I have come to realize that centralization of identities will not happen — during our lifetimes. The reasons are numerous, obvious, and beyond the scope of this post.
Where does this leave us on the essential question, i.e. how do we maintain identities now they must be distributed across the known universe?
The answer to this question will included within a series of blog posts. Stay tuned…
Frequently debated within info sec circles. Which one of them is better?
Use the right tool for the job as they say. RBAC, like any access control model, has its weaknesses. Many are well understood, even discussed by the original NIST team who framed the model.
However, there are a number of common fallacies wrt how RBAC works. For example…
1. RBAC is static. It cannot use contextual information e.g. time, user location, device type.
Constraints are commonly applied during user, role and permission activation in RBAC. For example, placing temporal constraints on a role activation. Indeed INCITS 494 prescribes their use:
5.4 RBAC Policy Enhanced Constraints
Enhanced constraints go beyond the INCITS 359 RBAC Standard by including additional types of constraints. Constraints on roles may be static or dynamic. Static constraints are applied off- line before the role is activated by the user. Dynamic constraints are applied on-line after the role(s) are activated. These enhanced dynamic constraints can introduce attributes into the RBAC environment.
INCITS 494-2012, p. 8
2. RBAC cannot perform dynamic segregation-of-duty.
RBAC supports dynamic SoD constraints. From the spec:
5.3.2 Dynamic Separation of Duty Relations
Dynamic Separation of Duty Relations Static separation of duty relations reduce the number of potential permissions that can be made available to a user by placing constraints on the users that can be assigned to a set of roles. Dynamic Separation of duty (DSD) relations, like SSD relations, are intended to limit the permissions that are available to a user. However, DSD relations differ from SSD relations by the context in which these limitations are imposed. SSD relations define and place constraints on a user’s total permission space. This model component defines DSD properties that limit the availability of the permissions over a user’s permission space by placing constraints on the roles that can be activated within or across a user’s sessions.
ANSI INCITS 359-2004, p. 10
3. It relies on custom code within application layers (API, apps, DB…) to implement finer-grained controls.
Presumably what is meant here is that custom code must be written because RBAC controls don’t adequately satisfy security requirements for authorization.
Where are ABAC’s published functional specifications? Where are the standard object (data) and functional (api) model for computing (and storing) its decisions?
Perhaps it is better to use a proven, non-standard ABAC implementation than a custom app widget? If that is what is being said then I agree, but neither are ideal.
ABAC has its place as does RBAC. Knowing when to use one, the other, or both, is important. Understanding the limitations and strengths of each is crucial before adequately addressing the challenges we face as security practitioners.
After passing the half century mark a few years ago, I find myself in a quandary over exercise. Damned if I do and damned if I don’t. That’s because the aging process brings on arthritis, obesity, diabetes, heart disease and a host of other conditions. The natural inclination at this stage is to start taking it easy, but what’s really needed is to maintain an active physical fitness regime.
The problem is activities learned in youth do more harm than good during the middle years. For example the fifty-something’s heavy bench presses will surely tear a rotator cuff in their shoulder. The resulting injury exacerbates the natural aging condition, further prolonging and encouraging inactivity, which induces declining function of the body.
Exercise when done correctly, has the opposite effect, prolonging vigorous activity beyond the middle years into old age. But in so doing, its focus needs to be on using increased repetitions and lighter weights to reduce the strain placed on tendons. This will enable muscle growth which improves skeletal stability while preventing overuse injuries. With that in mind, here are eleven commandments for keeping fit into 2017 and beyond.
- I will not not use barbells.
- I will not use heavy weights during strength training exercises.
- I will work my legs at least once per week.
- I will superset between opposing muscle groups, to keep my heart rate elevated.
- I will work a different type of core exercise on every strength training day.
- I will keep my strength training workouts short, less than 30 minutes per day.
- I will perform strength training exercises often, between 3 and 5 times per week.
- I will perform cardio exercises, preferably outside, at least 3 times per week, and a duration of 60 minutes or more.
- I will eat more than 5 cups of fruits and vegetables per day.
- I will sleep at least 7 hours per night.
- I will take at least one rest day per week.