Security

Lt Gorman, you need this software!

Posted on 5 February 2019 by David Navarre

How can I be grumpy at a tech conference? Well, it’s not one of my familiar conferences. That one’s next week, but I’m not going. We’re moving off of Notes, though a part of me continues to bleed yellow. So, I’ve been stomping around, feeling a little grumpy about having to give up my familiar technology and attending conferences with my friends.

The best thing about technology conference is… technology! So, I saw a session with the relatively boring title of “Real Time Data Analytics to the Edge”. OK, I admit, tossing in the word “Analytics” is what caught my eye, because it’s a buzzword. When I look at horse racing, I dive deeply into the data and use analytics to help me understand the possible outcomes and their likelihood. The description sold it a bit better:

Speed of command and safety is a top priority for governments. Delivering on the intelligent edge is made possible by Microsoft Azure. The “edge” is where the operational action lives and is ever present at the very skin of an organization. It’s the convergence of compute, connectivity, and cloud. The intelligent edge is about enabling operations, collaboration, and IoT sensor fusion amongst responders and far forward commanders yet leverages centralized services to augment decision making where the decision space is measured in minutes and in worst case scenarios, seconds. Blueforce Development and Dejero will show how sensor fusion, cognitive services, and mobile connectivity put the power of actionable intelligence in the hands of the frontline users, powered by Microsoft Azure, in real-time.

This still doesn’t convey the coolness of the technology involved.

Go back with me, if you will, to Aliens and sit down with Lieutenant Gorman, commanding his squad of Colonial Marines. Each of your Marines is wearing cameras and sensors to feed back information to their commander. Unfortunately, there’s too much data for him to handle and his lack of experience contributes to his failure. Nonetheless, what cool tech! He can see what any of his Marines can see. He can monitor all of their vitals. He should even be able to pick up movement around them from the sensors.

What BlueForce does is take all that data and make it manageable. I remember taking a course in management way back in the day and among the best ideas was “management by exception”. I use this all the time in software development – I want the system to only notify me when something’s broken. I also like to get occasional messages that just remind me that the system is running (since it might not be able to send a notice if a whole lot is broken!) BlueForce lets the user, in this case our neophyte Lieutenant, take the feeds he wants and arrange them the way he wants to know what’s going on.

In the “It’s a small world” category, the CEO of BlueForce Development is Michael Helfrich, who was Director of Product Development for Knowledge Management at Lotus. So, we were able to share stories about Raven, which I was never able to get any of my customers to buy, since no one could afford $100,000 in 1999!

Among the feeds was the Virtual Surveillance Partner (VSP) by 6-Watch. It uses a combination of Lidar and video to perform threat detection (helping sort out what’s important and what’s not) and provide audio cues about those threats. There are far more applications to this set of tools than just providing our Colonial Marine Lieutenant with real-time threat assessment and asset management, but I suspect anyone reading this is going to hop onto their website to see more about it. (Think “law enforcement” and “forensic evidence”.)

So, the good Lieutenant would have been able to put his VSP up on the screen, select which video feeds matter, perhaps enabling alerts for various vital stats feeds from his Marines and figure out how best to command the situation. After all, he had 38 drops (simulated) to practice it.

20190205_140111.jpg

The command center screens that Lt Gorman would be able to drag-and-drop to configure his feeds to best command those Colonial Marines

It’s some pretty cool stuff and the President of 6-Watch, Eric Gahagan, took some time to chat with me as I was looking at their system in action on the conference floor. Eric spent a long time with the Massachusetts State Police, so the implementation of their products is near and dear to his heart.

20190205_135931.jpg

The Lidar for 6-Watch is atop that tripod. The crate below is just for packing it up for shipping. So, it’s somewhat portable – a Special Forces team could easily mount it on a vehicle.

As much as I struggle with being an “outgoing introvert”, meeting the people who are behind the technologies and making connections has always been the great benefit of going to tech conferences. I can’t say that I’ll ever personally have a use for the technology, but it’s pretty cool.

Advertisement
Categories: Bleed Yellow, Conferences, Security | Tags: , , , , , , , , , , , | 1 Comment

Finding user roles in #XPages

Posted on 6 January 2014 by David Navarre

I’ve written a piece before on roles in XPages, but since that dealt with using the ACL to limit access to a page and not about the programmatic use of roles, I wanted to return to the issue.

Back in old Notes, if we wanted to hide something based if the user did not have a certain role in the ACL, we could use a pretty simple formula:

!@IsMember(“[roleNameHere]”; @UserRoles)

Remarkably, it’s not that much harder in XPages, but there are some important wrinkles to be concerned about. As noted previously and by Russ Maher on his blog, you must remember to use your brackets [] and also keep in mind the result you want (true or false). Remember that the XPages formulas are ‘rendered’ formulas, meaning you want to ‘true’ to display the result and ‘false’ to hide it, so you’d use:

@IsMember(“[roleNameHere]”, context.getUser().getRoles());

Here’s the more complete source code for the rendered formula:

<xp:this.rendered><![CDATA[${javascript:@IsMember("[Testing]", context.getUser().getRoles());}]]></xp:this.rendered>

Now, I’m not sure what impact of referencing the user roles that way has on performance, but since I now I’m using them in many rendered formulas all over my application, I decided to compute it once and then reuse it many times. I put a few extra lines into a control that’s on my main application layout control to drop it into a sessionscope variable. I suppose I might shave a millisecond off if I only computed that once per session, but I didn’t go that far.

<xp:this.beforePageLoad>
<![CDATA[${javascript:var roles = context.getUser().getRoles();
sessionScope.userRoles = roles;}]]>
</xp:this.beforePageLoad>

Then, in order to check to see if my user has one of three roles when rendering an item, I could use this code:

<xp:this.rendered><![CDATA[${javascript:var manager = @IsMember("[InventoryMgr]", sessionScope.userRoles);
var viewer = @IsMember("[InventoryViewer]", sessionScope.userRoles);
var grantsManager = @IsMember("[InvMgrGrants]", sessionScope.userRoles);
if ( manager || viewer || grantsManager ) { return true };
return false; }]]>
</xp:this.rendered>

Now, I also found that sometimes I need to determine the user’s role in my Java code. That’s also not that hard, except that vectors are not quite arrays. If there is a single value, it’s not the same as a multiple value vector. I’m not sure if this is a Notes implementation issue or if it’s the way Java always handles vectors. That is, if it’s a single value, it puts our brackets [] around the value, but it does NOT for multiple values. So, when I was using the code written for us, it wasn’t always picking up the roles correctly. Once I simply told it to check both ways, our code worked more cleanly. (The reference to ExtLibUtil comes from the original code, so I didn’t modify it.)

public Vector getCurUserRoles() {
	try {
		curUserRoles = ExtLibUtil.getCurrentDatabase().queryAccessRoles(ExtLibUtil.getCurrentSession().getEffectiveUserName());
	} catch (NotesException e) {
		this.debug("getCurUserRoles ERROR: " + e.getMessage(), "error");
		curUserRoles = new Vector();
	}
	return curUserRoles;
}

public boolean hasRole(String role, String uname) {
	try {
		Vector roles = this.getCurUserRoles();
		if (roles.contains(role))
			return true;
		if (roles.contains("["+role+"]"))
			return true;
		return false;
	} catch (Exception e) {
		this.debug("hasRole ERROR: " + e.getMessage(), "error");
		return false;
	}
 }

Note that the debugging uses Mark Leusink‘s DebugToolbar, which I highly recommend to everyone.

Categories: Java, Old Notes, Security, Xpages | Tags: , , , , , , | 2 Comments

Using XPage ACLs to limit access

Posted on 30 July 2013 by David Navarre

Among the items I’d been working on for the presentation at the DCLUG earlier this month was an evaluator’s page.

Now before I get into the code snippet, let me lay out a bit more of the design concept to put this in context. Users would anonymously create grant requests via browser, then internal users would assign evaluators with their Notes clients, and those evaluators would login via browser to fill out their assessments of the requests. So, I needed to come up with a way to force the logins and inhibit anyone who wasn’t authorized from seeing the evaluators work lists or assessments.

Notes does this wonderfully well, but as I’m breaking new ground with XPages, I had to search around for clues on how to do it. After a while, I did finally find something on my go-to source, Stack Overflow. (Thanks to Matt White and AndrewGra!)

<xp:this.acl>
    <xp:acl>
       <xp:this.entries>
          <xp:aclEntry type="ANONYMOUS" right="READER"></xp:aclEntry>
          <xp:aclEntry type="DEFAULT" right="EDITOR"></xp:aclEntry>
       </xp:this.entries>
    </xp:acl>
 </xp:this.acl>

While this is nice, it also opened me to wondering about all the other options of the aclEntry control. There are 5 parameters to be considered. The two required parameters are intriguing.

type – string – Defines type of entry, valid values are USER, GROUP, ROLE, ORGUNIT, ORGROLE, DEFAULT, ANONYMOUS

While both ORGUNIT and ORGROLE are deprecated, the other 5 are quite familiar. If you set type to either DEFAULT or ANONYMOUS, you don’t supply any of the name values, since these are effectively “unnamed” access types. For USER, GROUP and ROLE, you must supply name values.

right – string – Defines rights for this entry, valid values are NOACCESS, READER, EDITOR

On an XPage, you really are only concerned about end-user access, so it’s either none, reading or editing. Distinguishing between Author and Editor depends on the ACL and whether their are Author names fields on the source documents, so not something one wants the XPage monkeying around in anyway.

Since neither DEFAULT nor ANONYMOUS requires any name information, the next two parameters are optional.

fullName – string – Defines users full name e.g. John Smith

name – string – Defines entry name

There’s a real lack of clarity here as to what goes where, in particular, what to do about ROLES. Is it a name or a fullName. Do you use brackets [ ] or just the text? So, I fiddled around. I’d almost figured out how to implement ROLES myself when I searched just a bit more and found Russ Maher’s guidance. Basically, put brackets around the name value and straight text for the fullName. Here’s my ACL to limit the XPage to only those users with the Evaluator role.

<xp:this.acl>
	<xp:acl>
		<xp:this.entries>
			<xp:aclEntry type="ANONYMOUS" right="NOACCESS"></xp:aclEntry>
			<xp:aclEntry type="DEFAULT" right="NOACCESS"></xp:aclEntry>
			<xp:aclEntry fullName="Evaluator" right="EDITOR" type="ROLE" name="[Evaluator]">
			</xp:aclEntry>
		</xp:this.entries>
	</xp:acl>
</xp:this.acl>

The final parameter is also optional.

loaded – boolean – Specifies whether or not the tag instance should be created when the page is loading. Value defaults to ‘true’.

This one is obviously for people far more clever than I. I suppose that if you want the ACL to only take effect after some other event that trips the loaded flag to true or something. I’m not real sure. It is inherited from com.ibm.xsp.BaseComplexType if that helps you figure it out.

Just as form access and creation controls are very sneaky, these are as well. Since the properties don’t show up in the nice little properties box for the XPage and you have to hunt into either the source or the All Properties tab (under data), they are sure to create some trouble-shooting issues, especially when you’re new to XPages. So, I’d recommend you make sure to put these at the top of your XPages and I would be careful about using them on custom controls, unless you do everything in your custom controls, simply because of the lack of visibility.

Hope that helps someone looking for help with security in their XPages. I’m pretty happy with how easy it turned out to be to code it.

Categories: Security, Xpages | Tags: , , , , , , , , , | 4 Comments

Create a free website or blog at WordPress.com.

%d bloggers like this: