COmanage Users List

[Scott Koranda <>]

Hi,

I spoke with Paul directly about this, but for the benefit of the
email archive...

My recommendation when putting COmanage and other SPs behind an IdP/SP
proxy is that the proxy NOT filter the attributes from the eduGAIN IdPs
sent to COmanage, but instead just pass them through.

For the other SPs you usually want the proxy to take the attributes
from an eduGAIN IdP, use ePPN or ePUID or whatever as an index to
look up the user in an attribute store (usually populated by COmanage),
and find the VO attributes to send to the SP.

But for COmanage you usually want to not do that and just have the proxy
pass through the attributes from the eduGAIN IdP so that COmanage
can consume them directly.

Thanks,

Scott K

> In a situation where COmanage is behind a collaborative proxy (one that is
> adding/modifying attributes), a user’s ePPN, as seen by SAML assertions to
> COmanage, will change once the user is enrolled (at least in our setup
> currently).
> 
>  
> 
> That’s because a CO Identifier is generated and written to LDAP as the 
> user’s
> eppn.
> 
>  
> 
> Now, as I understand it, COmanage should be OK with this as long as the 
> “Login”
> property on the identifier assignment is checked (and it is).  But, it’s not
> working.  After enrolling, subsequent login attempts by an enrolled user are
> met with the error:
> 
>  
> 
> The identifier "<your CO-assigned ID>" is not registered. If your request 
> for
> enrollment is still being processed, you will not be able to login until it 
> is
> approved. Please contact an administrator for assistance.
> 
>  
> 
> But, the referenced ID is most definitely registered to the right CO Person.
> 
>  
> 
> When I double-checked the COmanage doc, I found this:
> 
> “Login: In general, CO Person identifiers are not used to log in to COmanage
> services (Organizational Identities are), so this should generally be left
> unchecked.”
> 
> So, what’s the right way to do this?  Obviously, I could send the right 
> thing
> from the proxy and then give it a priority mapping to REMOTE_USER in the
> COmanage Shibb SP, but that doesn’t feel like the right way…
> 
>  
> 
> Are there other ways of doing this?
> 
>  
> 
> Thanks!
>