Idp3.0 Login Intercept

[Cantor, Scott]

> Could you please let me know how to intercept the login process and based
> on the attribute retrieved from the authentication source (Active Directory)
> show different UI before releasing attributes to SP.

Eventually, but not in any time frame you'll probably be ok with.
 
> For example, one use case might be if the user password is not changed after
> certain number of days, when the user login corresponding AD attribute
> needs to checked and based on the attribute value either forced password
> reset UI needs to be shown or release the attributes to SP.

One way of doing that out of the box or with a simpler starting point is the context-check intercept, which evaluates a condition bean against the state of the system and produces a ContextCheckDenied event if the condition isn't true.

The example condition in intercept/context-check-intercept-config.xml is something that looks for the mere presence of an attribute, and you could produce something in the resolver that means the transaction should be blocked, and then do a NOT condition around checking for it.

You can also use that flow as an example to copy from to create your own version if you want to leave the original alone.

To create a flow called myintercept, for example, you need the flow definition to be in ${idp.home}/conf/flows/intercept/myintercept/myintercept-flow.xml.

> Could you please let me know the steps, the bean & xml files need to be
> created and the corresponding xml files need to be updated.

Eventually, but not until somebody, me or otherwise, reaches that stage of documentation work. We are simply not resourced to document the entire thing overnight, and our focus is on documenting functionality people already rely on.

-- Scott