Inadequate "target URL" type detail provided from the IDP audit events in the "DataContext" column of a parsed event (using Sentinel 6.2 and 7.0).
Today, when a user accesses a protected resource on an AG cluster and is redirected to login at the IDP, after the user successfully authenticates the IDP just prints the AG cluster's ESP URL in the event -- which is too generic and not informative at all.
Obviously, the IDP knows about the exact Proxy Service / protected resource URL that the user is really going to visit because within the client browser if you View Source on the login page that the IDP itself has generated for you, there is a hidden input field called "TARGET" that has been filled in with the precise Proxy Service URL location you tried to visit before being sent to the IDP.
We have well over 100 Proxy Services, so for the IDP's to generically report back only the AG's ESP URL as the target in every audit event for authentications is practically useless information. Far better to give us an indication of where the user was actually off to go visit.
IDP URL: https://beta-idp.MyCompany.com
AG's ESP URL: https://beta-auth-https.MyCompany.com
Proxy Service URL originally accessed: https://www.mycompany.com/somepath/somefile
- Stefan
Today, when a user accesses a protected resource on an AG cluster and is redirected to login at the IDP, after the user successfully authenticates the IDP just prints the AG cluster's ESP URL in the event -- which is too generic and not informative at all.
Code:
Severity EventTime EventName Message XDASTaxonomyName XDASOutcomeName InitUserName InitUserDomain InitUserFullName InitUserDepartment EffectiveUserName InitHostName InitIP InitAssetFunction InitServicePortName TargetUserName TargetUserDomain TargetUserFullName TargetUserDepartment TargetHostName TargetIP TargetAssetFunction TargetServicePortName TargetTrustName FileName DataContext ObserverHostName ObserverIP MSSPCustomerName ReporterHostName ReporterIP
0 1/21/2012 15:32 NIDS: User session was authenticated AMDEVICEID#esp-73768320D7C25697: AMAUTHID#6A4BDE9482F944211989FDCDF4C86916: User session was authenticated: [cn=JohnSmith,o=Company]. Authentication Type: [https://beta-auth-https.MyCompany.com:443/nesp/idff/metadata] Authenticating Entity Name: [null] Contract Class or Method Name: [name/password/uri] XDAS_AE_CREATE_SESSION XDAS_OUT_SUCCESS 192.168.218.224 Novell Access Manager cn=JohnSmith,o=Company metadata https://beta-auth-https.MyCompany.com:443/nesp/idff 192.168.218.224 unknown 192.168.218.224
0 1/21/2012 15:32 NIDS: Provided an authentication to a remote consumer AMDEVICEID#0881CFF5BBF0D19A: AMAUTHID#F7EC674AB8C2190B4ABE4E48FB272101: Provided an authentication to a remote consumer on behalf of user: [cn=JohnSmith,o=Company]. Authentication Type: [https://beta-idp.MyCompany.com/nidp/idff/metadata] Authenticating Entity Name: [https://beta-auth-https.MyCompany.com:443/nesp/idff/metadata] Contract Class or Method Name: [name/password/uri] XDAS_AE_CREATE_SESSION XDAS_OUT_SUCCESS 192.168.218.169 Novell Access Manager cn=JohnSmith,o=Company metadata https://beta-idp.MyCompany.com/nidp/idff 192.168.218.169 unknown 192.168.218.169Obviously, the IDP knows about the exact Proxy Service / protected resource URL that the user is really going to visit because within the client browser if you View Source on the login page that the IDP itself has generated for you, there is a hidden input field called "TARGET" that has been filled in with the precise Proxy Service URL location you tried to visit before being sent to the IDP.
We have well over 100 Proxy Services, so for the IDP's to generically report back only the AG's ESP URL as the target in every audit event for authentications is practically useless information. Far better to give us an indication of where the user was actually off to go visit.
IDP URL: https://beta-idp.MyCompany.com
AG's ESP URL: https://beta-auth-https.MyCompany.com
Proxy Service URL originally accessed: https://www.mycompany.com/somepath/somefile
- Stefan