Security

Hey Frank, hows things?

If your can create 'custom-code', and I'll assume we're talking EIP here, then the approach is to use the HTTP authorization source. A Content-Server/Context-Server-Action cannot return and ingest the response body from an API call to EIP {or any other system}, a CS is a PUSH only.

Use the HTTP authZ source to consume the response, easiest if you return a JSON body, then expose this into the enforcement policy..... DONE :-)

Easiest to not use nested JSON but CPPM can decode it, it just gets more complicated.

Hi Danny,

Yes, we are using EIP, and that makes a lot of sense - it certainly explains why I couldn't find what I was looking for around context servers!  I do have a couple of follow up questions:

• Will the attributes sent back be saved as endpoint attributes?
• If not, will they be referenced via the same names in my enforcement policy, or do I have to write everything to basically say "if endpoint:ipam-status OR eip-autz:ipam-status"?

Thanks!

Hey Frank, hows things?

If your can create 'custom-code', and I'll assume we're talking EIP here, then the approach is to use the HTTP authorization source. A Content-Server/Context-Server-Action cannot return and ingest the response body from an API call to EIP {or any other system}, a CS is a PUSH only.

Use the HTTP authZ source to consume the response, easiest if you return a JSON body, then expose this into the enforcement policy..... DONE :-)

Easiest to not use nested JSON but CPPM can decode it, it just gets more complicated.

So I've attached an OLD TechNote for Msoft Intune and CPPM integration, this is now out-of-date as the integration moved to a different framework around polling, where this was a real-time API driven process, exactly what you want with EIP.  The pages in the DOC hopefully make it clear how to do what you want, if not let me know.  Take a look specifically at pages 24 - 27.

Any questions let me know here, this is using an extension as a proxy to Intune, but that in terms of the config and how the data is exposed back into CPPM is mute IMO. 

Hi Danny,

Yes, we are using EIP, and that makes a lot of sense - it certainly explains why I couldn't find what I was looking for around context servers!  I do have a couple of follow up questions:

• Will the attributes sent back be saved as endpoint attributes?
• If not, will they be referenced via the same names in my enforcement policy, or do I have to write everything to basically say "if endpoint:ipam-status OR eip-autz:ipam-status"?

Thanks!

Hey Frank, hows things?

If your can create 'custom-code', and I'll assume we're talking EIP here, then the approach is to use the HTTP authorization source. A Content-Server/Context-Server-Action cannot return and ingest the response body from an API call to EIP {or any other system}, a CS is a PUSH only.

Use the HTTP authZ source to consume the response, easiest if you return a JSON body, then expose this into the enforcement policy..... DONE :-)

Easiest to not use nested JSON but CPPM can decode it, it just gets more complicated.

Time to double team Danny :)

Page 25 of the document says "Its mandated that a Login Username/Password is entered, but is not used, this it can be anything".  Are the credentials simply not required to communicate with the Intune URL as entered ... or are the credentials never used?

v6 of EfficientIP SOLIDServer has an API which requires the username and password to be base64 encoded as HTTP headers when making the request.  I assume ClearPass is not setup to handle an API such as that - though I would love you to prove me wrong.

------------------------------
Ben Higgins
------------------------------


Original Message:
Sent: Dec 22, 2020 05:44 PM
From: Danny Jump
Subject: Guide to creating custom endpoint context servers

So I've attached an OLD TechNote for Msoft Intune and CPPM integration, this is now out-of-date as the integration moved to a different framework around polling, where this was a real-time API driven process, exactly what you want with EIP.  The pages in the DOC hopefully make it clear how to do what you want, if not let me know.  Take a look specifically at pages 24 - 27.

Any questions let me know here, this is using an extension as a proxy to Intune, but that in terms of the config and how the data is exposed back into CPPM is mute IMO. 

Hi Danny,

Yes, we are using EIP, and that makes a lot of sense - it certainly explains why I couldn't find what I was looking for around context servers!  I do have a couple of follow up questions:

• Will the attributes sent back be saved as endpoint attributes?
• If not, will they be referenced via the same names in my enforcement policy, or do I have to write everything to basically say "if endpoint:ipam-status OR eip-autz:ipam-status"?

Thanks!

Hey Frank, hows things?

If your can create 'custom-code', and I'll assume we're talking EIP here, then the approach is to use the HTTP authorization source. A Content-Server/Context-Server-Action cannot return and ingest the response body from an API call to EIP {or any other system}, a CS is a PUSH only.

Use the HTTP authZ source to consume the response, easiest if you return a JSON body, then expose this into the enforcement policy..... DONE :-)

Easiest to not use nested JSON but CPPM can decode it, it just gets more complicated.