Re: [openxdas-devel] Peer associations?

[Wayne H. <wh...@no...>]

Thanks David for your quick response. It makes sense. The term
"Location" confused me. John, can you confirm David's comment?

Now let me ask another question: I understand that OpenXDAS only uses
generic event number like XDAS_AE_MODIFY_DATA_ITEM_ATT but from
application's perspective many differnt events could use that same one.
For example, application updates a column in a database table or an
entity in eDirectory uses the same event number,
XDAS_AE_MODIFY_DATA_ITEM_ATT. How could the Analysis softwre distinguish
between these two events? I know that we could store this information in
the EVT section, but it seems to me this information is important enough
to warrant a field in the header section. It would be quite useful if it
also conforms to the OpenXDAS name. For example, I could call this field
component and stores "IDM/UserApp/Entity/DeleteEntity" in there. In this
way, I can create many useful reports based on the hierarchy.

Wayne Hsu
Senior Software Engineer,
eXtend Engineering
(703) 967-4980
Novell, Inc., the leading provider of Net Business Solutions.
www.novell.com


>>> David Corlette 04/27/07 1:31 PM >>>
Hi Wayne,

I've included what I think below:

>>> On Fri, Apr 27, 2007 at  1:06 PM, Wayne Hsu wrote: 
> An IDM User application runs in a Linux server but the user identity
is 
> stored and authenticated through eDirectory in another Linux server.
One 
> event is generated when the administrator whose DN in eDirectory is 
> “cn=admin,ou=idmsample,o=novell” changed the password of a user “whsu”
whose 
> DN is “cn=whsu,ou=idmsample,o=novell”. Let’s say user “whsu” is the
target. 
> What will be the data being stored in those target fields? I filled up
the 
> XDAS fields with the following data based on my understanding of the
field 
> definition. As you can see, I am missing the most important data: the
name of 
> the user whose password has been changed. Also, can we say that user
whsu is 
> located in the <host name>/IdmUserApp but is authenticated by the
<host 
> name>/eDirectory?
> 
> Event Number: XDAS_AE_MODIFY_AUTH_TOKEN
> Initiator Authentication Authority: <host name>/eDirectory
> Initiator Domain-Specific Name: cn=admin,ou=idmsample,o=novell
> Initiator Domain-Specific ID: cn=admin,ou=idmsample,o=novell
> Target Location Name: <host name>/eDirectory
> Target location address: url to the eDirectory
> Target Service Type: ldap
> Target Authentication Authority: host name>/eDirectory
> Target Princial Name: don’t know  (User name under which eDirectory is

> running)

No, I think the target in this case is the user, not eDirectory.  So I
would put the username in this field.  I imagine there will actually be
a couple events generated here, one by the User App and one when eDir
receives the password change (the attempt and the result, so to speak).

> Target Principal ID: don’t know (User ID under which app server is
running)


> I also have the following questions:
> 
> 1.	What’s the value of Target Princial Name/ID? In most cases, we
don’t know 
> or care about that information. 

That's why I think in this case the target is the username.

> 2.	Like wise, what’s the value of the
Originator/Initiator/TargetPrincipal 
> ID? Can’t the Original/Initiator/TargetPrincipal Name be enough? In
most 
> cases, we don’t know or care about the ID. I know we can hard-code
root ID to 
> 0, but what's the value of it? For user other than root, it is
difficult to 
> obtain the ID without the administor privilege in the authentication
service. 

I somewhat agree, but in some cases events I have seen include both
pieces of information.  Also consider the case where the target is a
network port - in this case the name/ID of the port can be trivially
retrieved from the services file.




HTH