Layer7 Access Management

Expand all | Collapse all

SAML SP multiple authlevels for a single IdP

  • 1.  SAML SP multiple authlevels for a single IdP

    Posted 03-10-2015 12:40 PM

    Ok the SAML setups needed for SiteMinder are insanely confusing and not straight forward at all -- been pouring over the docs which haven't been any real could really use some pointers here.


    I've got a very simple requirement to have a single remote IdP. I need to create SMSESSION at appropriate level depending on the authentication context returned.



    Request 1 - Send TimeSyncToken and IdP enforces two-factor token authentication. Response assertion contains the "TimeSyncToken" class and SiteMinder creates a session at Level 3


    Request 2 - Send Smartcard and IdP enforces smartcard authentication.Response assertion contains the "TimeSyncToken" class and SiteMinder creates a session at Level 4.



    Is this doable with SiteMinder? If so, how can I do this when an SP -> IdP partnership only has one level assigned (even though you can assign multiple context references)? And how do you dynamically send different contexts in a request (i.e., same partnership send context A in request 1 and context B in request 2)?

  • 2.  Re: SAML SP multiple authlevels for a single IdP

    Posted 03-12-2015 01:11 PM

    So looks like quickest way is to head down the route of 2x IdP entityIDs - at least the IdP is in our control so doable for now to quickly address it.


    Seems silly to not allow 2x active IdPs at the same time. I should be able to differentiate them based on the "NAME" I assign to them instead of entityID. This would easily allow for creating dynamic-like capabilities without having to make any big product changes or custom coding. Then IdP config 1 could pass and validate contexts A at Level B and then config 2 could pass and validate contexts X at Level Y.


    I do see an option that query parameter overrides the configuration on the authncontext menu. However, don't see what to pass it. Can pass the context itself as a query string but still passes the configured value. The wiki site doesn't indicate a way to change the context on the fly per request; and even then no way to dynamically change the level so basically any single IdP is locked into one authlevel.


    Long-term the IdP setup for context processing really needs to map the authlevels to the contexts. This would support step-up type functionality and allow an external IdP to essentially generate SMSESSION at the appropriate level based on how the user logged into them after SiteMinder validates the returned context.