authentication - LDAP vs SAML Authorization -

i'm investigating moving asset tracking system ldap saml. there 2 main areas our software uses ldap. first authentication. in order access system today need authenticate ldap , member of specified ldap group. part simple move on saml. we've utilized library handle of dirty work. , on idp can add claim authorize user. our second use of ldap throwing me loop.

today, each asset maintain has ability linked username. example, particular printer may belong 'someuser'. 1 of options our software gives administrator view/interact assets based on ldap user groups. administrator, may want update printers owned people in particular department. accomplish this, administrator create rule scoped ldap group 'departmentinquestion'. our software use service account connect ldap, create query see users our system in 'departmentinquestion', execute , use results determine assets should update.

so far searching have not been able find saml workflow analogous this. appears opportunity have asses 'someuser' when authenticate , access claims. in our workflow 'someuser' may never authenticate us. it's if we're using authorizing user on behalf of service account. there existing workflow i've overlooked during exploration? there other technologies support authorization in manner?

thanks input!

saml passport or visa. has (trusted) information can used know (e.g. name, dob) , infer can access (e.g. entrance country). can use properties in token query other systems additional information might associated (e.g. bank statement).

so, analogously, saml typically used authenticate users system (once trust it's origin), there're no provisions managing user profiles, or 'resources'.

authorization decisions, if any, made based on attributes associated user (e.g. group belongs to) , conveyed in claims in security token.

perhaps 1st questions answer why want move away ldap , thinking saml. because want accept users logging in own credentials? because want rid of ldap server altogether

you keep ldap server managing resources associated users, , authenticate users somewhere else. have now. correlate users "outside" , "inside" via common attribute (e.g. username, or id).

if want rid of ldap together, you'd need someplace else store information (e.g. app database).